Роль uml в базах данных на сегодняшний день

Идеи, которые иллюстрирует рис. 3.16, представляются довольно туманными в том, что касается применимости объектного мышления к построению и функциониро­ванию баз данных. Такая объектно-ориентированная нотация не согласуется с обы­чаями и процедурами, принятыми в коммерческих базах данных сегодняшнего дня. Понятие о том, что атрибут сущности может быть скрыт внутри объекта, не имеет смысла, если только база данных не обрабатывается исключительно объект­но-ориентированными программами; но даже если так, эти программы должны

обрабатывать данные в соответствии с этой политикой. За исключением специа­лизированных объектно-ориентированных СУБД (ООСУБД) и их приложений, так никогда не делается.

Напротив, большинство коммерческих СУБД позволяют всем видам программ обращаться к базе данных и обрабатывать любые данные, в отношении которых у этих программ имеются соответствующие полномочия. Более того, с такими средствами, как генератор запросов в Microsoft Access 2002 (см. рис. 2.6), просто не существует способов ограничить доступ к значениям атрибутов отдельного объекта.

Итак, все сводится к необходимости знания о том, как интерпретировать диа­граммы «сущность—связь», выполненные в стиле UML. Они точно так же при­годны для проектирования баз данных, как и традиционные ER-диаграммы. Однако на текущий момент объектно-ориентированная нотация, которая в них вводится, имеет весьма ограниченную практическую ценность. Дальнейшую информацию по этой теме вы найдете в главе 18.

Примеры

Лучший способ приобрести навыки работы с любым средством для моделирова­ния — изучать примеры и использовать это средство для создания своих собст­венных моделей. В оставшейся части этой главы описаны два примера, которые помогут вам справиться с вашей первой задачей. Проработав эти примеры, займи­тесь решением задач, приведенных в конце главы.

Пример 1: танцевальный клуб Джефферсона

Танцевальный клуб Джефферсона производит обучение танцам и предлагает ин­дивидуальные и групповые занятия. Плата составляет $45 в час с человека или пары при индивидуальных занятиях и $6 в час с человека при групповых заняти­ях. Индивидуальные занятия проводятся на протяжении всего дня, с полудня до 22 часов, шесть дней в неделю. Групповые занятия проводятся по вечерам.

В танцевальном клубе работают два вида инструкторов: постоянные и прихо­дящие. Постоянные инструкторы еженедельно получают фиксированную зар­плату, а приходящие получают установленную сумму либо за вечер, либо за рабо­ту с конкретным классом.

Кроме занятий, танцевальный клуб Джефферсона два раза в неделю органи­зует танцевальные вечеринки с музыкальными записями. Входная плата состав­ляет $5 с человека. Танцевальный вечер в пятницу пользуется большей попу­лярностью и собирает в среднем около 80 человек; воскресный вечер собирает около 30 посетителей. Цель этих танцевальных вечеров — предоставить учени­кам место для практики. Еда и напитки не предусматриваются.

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

инструктором, а также иметь возможность подсчитать среднюю стоимость заня­тия у каждого инструктора.

Сущности

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

- индивидуальное занятие;

- групповое занятие;

- инструктор;

- постоянный инструктор;

- приходящий инструктор;

- вечер танцев;

- клиент.

Ясно, что словосочетания индивидуальное занятие и групповое занятие имеют между собой нечто общее, как и словосочетания постоянный инструктор и прихо­дящий инструктор. Одним из возможных решений будет определить сущность под названием ЗАНЯТИЕ с подтипами ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ и ГРУППОВОЕ,. ЗАНЯТИЕ, а также сущность ИНСТРУКТОР с подтипами ПОСТОЯННЫЙ_ИНСТРУКТОР и ПРИХОДЯЩИЙ_ИНСТРУКТОР. Кроме этих сущностей, в модели будут присутство­вать сущности ВЕЧЕР_ТАНЦЕВ _и КЛИЕНТ.

Как было отмечено в главе 2, в моделировании данных есть столько же от ис­кусства, сколько от науки. Решение, описанное только что, является лишь одним из возможных. Второе решение состоит в том, чтобы исключить сущности ЗАНЯТИЕ и ИНСТРУКТОР из списка, приведенного в предыдущем абзаце, и удалить все под­типы. Третье возможное решение — это исключить сущность ЗАНЯТИЕ (посколь­ку занятие нигде не упоминается само по себе как словосочетание), но оставить сущность ИНСТРУКТОР и ее подтипы. В данном случае мы выберем третий вари­ант, так как он представляется наиболее подходящим с точки зрения имею­щейся у нас информации. Таким образом, список сущностей будет выглядеть следующим образом: ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ, ГРУППОВОЕ_ЗАНЯТИЕ, ИНСТРУКТОР, ПОСТОЯННЫЙ_ИНСТРУКТОР, ПРИХОДЯЩИЙ_ИНСТРУКТОР, ВЕЧЕР_ТАНЦЕВи КЛИЕНТ.

Чтобы сделать правильный выбор среди этих альтернатив, необходимо про­анализировать требования и выяснить, каким образом данные требования отра­зятся на структуре системы. Иногда полезно рассмотреть атрибуты сущностей. Если, например, сущность ЗАНЯТИЕ не имеет никаких атрибутов, кроме иденти­фикатора, то вводить такую сущность нет необходимости.

Связи

Начнем с того, что сущность ИНСТРУКТОР имеет два подтипа: ПОСТОЯННЫЙ_ИНС-ТРУКТОР и ПРИХОДЯЩИЙ_ИНСТРУКТОР. Любой инструктор должен быть либо по­стоянным, либо приходящим, значит, подтипы являются взаимоисключающими.

Далее рассмотрим связи между сущностями ИНСТРУКТОР и ИНДИВИДУАЛЬНОЕ_ ЗАНЯТИЕ или ГРУППОВОЕ_ЗАНЯТИЕ. Инструктор может проводить много индиви­дуальных занятий и, как правило, индивидуальное занятие проводится одним инструктором. Но в ходе дальнейшего разговора с менеджерами танцевально­го клуба выясняется, что для продвинутых танцоров, особенно тех, кто гото­вится к соревнованиям, к индивидуальным занятиям иногда привлекается два инструктора. Поэтому связь между сущностями ИНСТРУКТОР и ИНДИВИДУАЛЬНОЕ_ ЗАНЯТИЕ должна иметь тип «один ко многим». По поводу групповых занятий мы, однако, будем полагать, что каждое из них ведет только один инструктор. Связи, описанные нами только что, изображены на рис. 3.17.

Клиенты могут посещать как индивидуальные, так и групповые занятия. Ино­гда индивидуальное занятие проводится с одним человеком, а иногда — с парой. Есть два способа моделирования этой ситуации. Можно определить сущность ПАРА как имеющую связь 1:2 с сущностью КЛИЕНТ, а можно допустить, что обе сущности, КЛИЕНТ и ПАРА, могут иметь связь с сущностью ИНДИВИДУАЛЬНОЕ_ ЗАНЯТИЕ. Мы предполагаем, что пары не посещают групповые занятия, а если и посещают, то этот факт не настолько важен, чтобы записывать его в базу данных. Эта альтернатива показана на рис. 3.18, а.

Существование сущности ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ зависит от сущностей КЛИЕНТ и ПАРА. То есть занятие не может существовать, если оно не проводится с каким-либо клиентом или парой. Число 1 рядом с горизонтальной линией, проведенной на рисунке под сущностями КЛИЕНТ и ПАРА, показывает, что в инди­видуальном занятии должны участвовать как минимум один клиент или одна пара, что разумно, поскольку индивидуальное занятие зависит от них.

Альтернатива заключается в том, чтобы не вводить пары, а указать тип связи между сущностями КЛИЕНТ и ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ как «многие ко многим». Если быть более точным, эта связь должна иметь тип «один или два ко многим», как показано на рис. 3.18, б. Хотя эта модель является не такой подробной, как модель на рис. 3.18, а, ее может быть вполне достаточно для нужд танцевального клуба Джефферсона.

Осталось рассмотреть возможные связи сущности ВЕЧЕР_ТАНЦЕВ с другими сущностями. Вечера танцев посещают как инструкторы, так и клиенты, и разработчики должны решить, важно ли показывать эти связи в структуре базы данных. Действительно ли для танцевального клуба важно знать, какие клиенты посетили какие танцевальные вечера? Так ли уж хотят менеджеры клуба вести запись посе­тителей в компьютерную информационную систему при входе в танцзал? И захо­чется ли посетителям, чтобы эти данные записывались? Скорее всего, эти связи не принадлежат к числу тех, которые требуется или следует хранить в базе данных.

Иначе обстоит дело со связью между сущностями ВЕЧЕР_ТАНЦЕВ и ИНСТРУКТОР. Хозяин клуба любит, когда на танцевальных вечерах присутствуют несколько клубных инструкторов. В связи с этим требованием правление клуба состави­ло расписание посещения вечеров инструкторами. Составление и запись этого расписания требуют, чтобы в базе данных присутствовала связь ВЕЧЕР_ТАНЦЕВ-ИНСТРУКТОР, которая имеет тип «многие ко многим».

Окончательный вид ER-диаграммы для танцевального клуба Джефферсона

На рис. 3.19 показан окончательный вид ER-диаграммы для модели, описанной в этом разделе. Мы не стали приводить на ней имена связей: хотя это сделало бы диаграмму более правильной по форме, при имеющихся у нас данных указание имен связей мало что прибавило бы.

Существование сущности ИНДИВИДУАЛЫНОЕ_ЗАНЯТИЕ зависит от сущности КЛИЕНТ, а ГРУППОВОЕ_ЗАНЯТИЕ — нет, потому что расписание групповых занятий составляется задолго до того, как на них записывается какой-либо клиент, и эти занятия будут проводиться даже в том случае, если ни один клиент не придет. Для индивидуальных занятий, однако, дело обстоит не так — они назначаются только по запросу клиента. Обратите также внимание, что в этой модели не представлены пары.

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

Проверка созданной ER-модели данных

Ошибки проще и дешевле исправлять на ранних стадиях процесса разработки базы данных, чем на поздних. Например, изменение максимального кардиналь­ного числа связи с 1:N на N:M на стадии моделирования данных сводится просто к внесению соответствующего исправления в ER-диаграмму. Но когда база дан­ных уже разработана и наполнена данными и написаны прикладные программы для ее обработки, такое изменение потребует значительной переделки, возможно, даже недель труда. Поэтому важно определить, какая модель данных требуется, прежде чем начинать ее воплощать.

Один из способов сделать это — рассмотреть ER-модель в контексте того, на какого рода запросы может ответить база данных со структурой, описывае­мой данной моделью. Взгляните, к примеру, на диаграмму, изображенную на рис. 3.19. На какие вопросы может дать ответ база данных, реализованная на ос­нове данного проекта?

- Какие и кем были проведены индивидуальные занятия?

- Какие клиенты посещали индивидуальные занятия у Джека?

- Кто является постоянным инструктором клуба?

- Какие инструкторы должны прийти на танцевальный вечер в пятницу?

При проверке модели данных вы можете формулировать такие вопросы и за­давать их пользователям, которых затем можно попросить составить свой спи­сок вопросов. Они могут задавать вопросы, касающиеся структуры базы дан­ных, чтобы проверить ее соответствие поставленным требованиям. Например, представьте, что пользователи спрашивают, какие клиенты посетили вечер танцев в прошлую пятницу. Разработчики модели данных, изображенной на рис. 3.19, должны прийти к заключению, что их структура неверна, поскольку на постав­ленный вопрос с помощью данной ER-модели ответить невозможно. Если требу­ется ответ на этот вопрос, необходимо ввести связь между сущностями КЛИЕНТ и ВЕЧЕР_ТАНЦЕВ.

Очевидно, что посредством такого неформального и нечетко структурирован­ного процесса невозможно доказать, что структура является правильной. Тем не менее, это прагматичный метод, пригодный для определения потенциальной правильности структуры. И даже такой метод все же лучше, чем отсутствие про­верки вообще!

Пример 2: бюро проката парусных яхт Сан-Хуана

Бюро проката яхт Сан-Хуана — это посредническая фирма, занимающаяся про­катом парусных яхт. Яхты не являются собственностью фирмы — она сдает их от имени владельцев, которые хотят получать доход от своих яхт, когда не пользуются ими. За свои услуги фирма Сан-Хуана берет плату. Фирма спе­циализируется на яхтах, которые могут использоваться для многодневных или недельных походов: самая маленькая из яхт имеет длину 28 футов, а самая боль­шая — 51 фут.

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

Важной составляющей обязанностей фирмы Сан-Хуана является учет обору­дования, имеющегося на яхтах. Многое оборудование является дорогим, а неко­торое, в частности то, которое не закреплено на яхте, может легко потеряться или быть украдено. В течение срока проката яхты ответственными за оборудова­ние являются клиенты.

Фирма Сан-Хуана ведет подробный учет клиентов и истории проката яхт. Это требуется не только для маркетинговых целей, но и для того, чтобы иметь

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

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

Яхты часто требуют обслуживания. Контракты, заключенные фирмой Сан-Хуана с владельцами лодок, требуют от фирмы ведения тщательной записи всех операций по обслуживанию и связанных с этим расходов, включая обычные опе­рации, такие как мойка или замена масла, а также внеплановые ремонты. Иногда ремонт может потребоваться во время рейса. Например, у яхты может отказать двигатель, когда она будет находиться далеко от доков Сан-Хуана. В этом случае клиенты вызывают по радио диспетчера фирмы, который определяет наиболее подходящее место для проведения ремонта и направляет персонал оттуда на ава­рийную яхту. Чтобы принимать все эти решения, диспетчерам требуется инфор­мация об имеющихся ремонтных доках, а также сведения о качестве и стоимости предыдущих ремонтов.

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

Сущности

Модель данных, требуемая для бюро аренды Сан-Хуана, более сложна, чем мо­дель для танцевального клуба Джефферсона. Потенциальные сущности показа­ны на рис. 3.20, а.

Рассмотрим сначала сущности, относящиеся к оборудованию. Есть много различных типов оборудования, и это наводит нас на мысль о введении подти­пов. Однако спросим себя: почему фирму Сан-Хуана должно интересовать обо­рудование? Фирме вовсе не нужно знать характеристики каждого предмета — например, длину цепи каждого якоря. В задачи фирмы скорее входит учет эле­ментов оборудования и их типов, чтобы можно было определить, что из оборудо­вания потеряно или повреждено. Таким образом, для данного случая мы отнесем все типы оборудования к одной сущности — ОБОРУДОВАНИЕ. Принадлежность оборудования указывается путем введения связи между сущно­стями ОБОРУДОВАНИЕ и ВЛАДЕЛЕЦ. Если фирма Сан-Хуана может быть экзем­пляром сущности ВЛАДЕЛЕЦ, то все оборудование, являющееся собственностью фирмы, может быть отнесено к этой сущности. Аналогичным образом, исходя из описанной ситуации, представляется безосновательным разделение оборудова­ния на закрепленное и не закрепленное на яхте. Точный список может быть со­ставлен и без такого разделения. Окончательный список сущностей приведен на рис. 3.20, б.

Обратите внимание, что АРЕНДА и РЕЙС являются синонимами: они относятся к одной и той же транзакции. Мы приводим здесь оба имени, чтобы можно было соотнести их с описанием ситуации.

Возможно, что сущности ПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ и ВНЕПЛАНОВОЕ_ТЕХ-ОБСЛУЖИВАНИЕ следует объединить. Один из способов определить, необходимо это или нет, — проанализировать атрибуты обеих сущностей. Если они одинако­вы, то два класса сущностей могут быть объединены. Заметьте также, что сущно­сти РЕМОНТ и ВНЕПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ определены как синонимы.

Связи

На рис. 3.21 изображена диаграмма «сущность—связь» для бюро аренды Сан-Хуана. По большей части представленные на этой диаграмме связи являются очевидными, но связь между сущностями ОБОРУДОВАНИЕ и АРЕНДА может быть предметом спора. Можно было бы сказать, что определенная часть оборудования должна быть отнесена к яхте (сущность ЯХТА), а не к аренде, или что часть обору­дования (а именно оборудование, которое закреплено на яхте) следует отнести к яхте, а оставшуюся часть — к аренде. Эти изменения представляют собой воз­можные альтернативы для структуры, показанной на рис. 3.21.

Кроме того, обратите внимание, что сущность ПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ связана с сущностью ЯХТА, в то время как сущность РЕМОНТ, или ВНЕПЛАНОВОЕ_ ТЕХОБСЛУЖИВАНИЕ, связана с сущностью АРЕНДА. Это подразумевает, что когда яхта не находится в аренде, никакого ремонта для нее не требуется. Может быть, это не соответствует действительности.

Наконец, сущности АРЕНДА и ПОГОДА_И_МАРШРУТ имеют связь 1:1, и они также имеют одинаковые идентифицирующие атрибуты. В связи с этим можно, а может быть, даже нужно объединить их в один класс сущностей.

Базы данных как модели моделей

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

Иногда при выявлении альтернатив команда, занимающаяся проектом, углуб­ляется в дискуссии по поводу того, какая модель данных наилучшим образом представляет реальный мир. Эти дискуссии исходят из ложных посылок. Базы данных не моделируют реальный мир, хотя распространено ошибочное мнение, согласно которому именно в этом и состоит их назначение. Базы данных явля­ются моделями пользовательских моделей мира (или, точнее, делового мира). Вопрос, задаваемый при выявлении альтернативных моделей данных, состоит не в том, насколько точно данная модель отражает реальный мир, а в том, насколь­ко точно она отражает имеющуюся в воображении пользователя модель среды, которая его окружает. Цель заключается в том, чтобы разработать структуру, ко­торая будет соответствовать представлениям пользователей.

Иммануил Кант и другие философы могли бы возразить, что людям не дано построить модель того, что существует на самом деле, и заявили бы, что суть вещей навсегда останется тайной для человечества⁵. Распространяя эту аргумен­тацию на компьютерные системы, Виноград (Winograd) и Флоре (Flores) выска­зали идею, что в обществах индивидуумы конструируют системы символов, которые позволяют им успешно действовать в мире. Последовательность симво­лов не является моделью бесконечности реального мира, а скорее представляет собой просто социальную систему, позволяющую пользователям успешно коор­динировать свои действия; ничего более по этому поводу сказать нельзя (Terry Winograd and F Flores, Understanding Computers and Cognition (Reading, MA: Addison-Wesley, 1986).

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

Резюме

Модель «сущность—связь» была разработана Питером Ченом. В этой модели опре­деляются сущности — идентифицируемые объекты, представляющие важность для пользователя. Все сущности данного типа образуют класс сущностей. Отдельная сущность называется экземпляром. Сущности имеют атрибуты, которые описы­вают их характеристики; один или несколько атрибутов определяют сущность.

Связи отражают взаимоотношения между сущностями. В ER-модели связи определяются явным образом; у каждой связи есть имя; существуют также клас­сы связей и экземпляры связей. У связей могут быть атрибуты.

Степень связи — это число сущностей, которые в ней участвуют. Большинство связей являются бинарными. Имеется три типа бинарных связей: 1:1, 1:N и N:M.

На диаграммах «сущность—связь» сущности изображаются прямоугольника­ми, а связи — ромбами. Максимальное кардинальное число связи указывается внутри ромба. Минимальное кардинальное число указывается с помощью пер­пендикулярной черты или овала. Связи, соединяющие сущности одного класса, называются рекурсивными. Атрибуты могут быть показаны на ER-диаграмме в эллипсах или в отдельной таблице.

Слабая сущность — это сущность, существование которой зависит от другой сущности; сущность, не являющаяся слабой, называется сильной сущностью. Слабые сущности изображаются с помощью прямоугольников со скругленными углами. Далее в этой книге мы определяем слабую сущность как сущность, логи­чески зависящую от другой сущности. Сущность может иметь минимальное кар­динальное число 1 в связи с другой сущностью, но при этом не быть слабой. Многозначные атрибуты представляются с помощью слабых сущностей.

Некоторые сущности имеют подтипы, которые определяют подмножества по­добных сущностей. Подтипы наследуют атрибуты от своего родителя, или надти-па. Связи типа «ИМЕЕТ» соединяют сущности разных типов, и идентификаторы у этих сущностей различны. Связи типа «ЕСТЬ» — это связи подтипов с их ро­дителями, и идентификаторы у сущностей, участвующих в такой связи, одинаковы.

Разработав модель данных, необходимо определить деловой регламент, ко­торый будет накладывать ограничения на возможные действия с сущностями. Каждая сущность в модели должна быть проанализирована на предмет возмож­ного добавления, изменения и удаления данных. Удаления, в частности, зачас­тую являются источником важных ограничений на обработку. Сформулирован­ные правила делового регламента необходимо документировать в модели данных.

Модель «сущность—связь» является важной частью многих CASE-продук-тов. Эти продукты предоставляют средства для конструирования и хранения ER-диаграмм. Некоторые из CASE-инструментов объединяют конструкции ER-модели с данными репозитория CASE. Унифицированный язык моделирования (UML) вводит новый стиль построения диаграмм «сущность—связь». Вам сле­дует иметь представление о диаграммах, выполненных в этом стиле; однако нуж­но понимать, что при проектировании базы данных не существует фундаменталь­ных различий между традиционным стилем и UML-стилем.

Завершив создание ER-модели, следует ее испытать. Один из способов это сделать — составить перечень вопросов, на которые можно ответить с помощью разработанной модели данных. Далее этот перечень показывается пользователям, которым предлагают подумать насчет дополнительных вопросов. Затем проверя­ется способность ER-модели ответить на эги дополнительные вопросы.

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