SQL Server). Microsoft Jet, и для SQL Server атрибут превращается в поле, а кортеж, соответственно - в запись. Эти соотношения практически взаимно однозначны; однако нужно помнить, что отно-на концептуальном уровне, в то время как наборы

записей и наборы результатов - на физическом. Модель данных

данных, то есть концептуальное описание предметной

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

Сущности

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

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

Приведем простейший пример: Покупатели покупают товары. Сотрудники продают товары покупателям. поставляют

товары . Существительные покупатели , товары , и

вне всякого сомнения, будут являться сущностями. События, описываемые глаголами покупать и также

являются однако здесь есть несколько тонкостей, неза-

метных на первый взгляд. Так, глагол описывает два раз-

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

Другая коварная ловушка полностью противоположна первой: два разных глагола ( покупать в первом предложении и продавать во втором) используются для описания одного и того же события, а именно приобретения товара покупателем. Это далеко не очевидный факт, и он чаще ускользает от внимания чем пер-

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

двумя вариантами описания одного и того же события, результатом которого является приобретение мистером N костюма. Однако в первом случае (покупка мистером N костюма у ателье) - это продажа уже готового костюма, а но втором (заказ костюма) - индивидуальный пошив. Это разные процессы, которые нельзя смешивать при создании модели.

Как правило, чтобы составить список сущностей, одной беседы с заказчиком недостаточно. Нужно просмотреть как можно больше документов, имеющих отношение к предметной области. Заполняемые бланки, отчеты vKiiiiif для персонала - это настоящая со-из которой и следует извлекать кандидаты в сущности. Причем анализировать документы следует предельно внимательно. Как правило, печатные документы достаточно инертны и могут не отражать самые последние изменения в инструкциях и иных [.нут-ренних правилах компании-заказчика. Будьте внимательны, если, например, столкнулись с сущностью, о которой заказчик в беседе ни разу не упомянул. Не следует сразу же предполагать, что он просто что-то забыл. Возможно, это просто наследие прошлого , уже не имеющее никакого отношения к текущему состоянию дел в нии. Вам обязательно следует это проверить.

После того как составлен первоначальный вариант списка сущностей, следует обязательно проверить его на полноту и связность. Кроме того, нужно выявить дубли , то есть сущности, и сущности, на самом деле разные, но ошибочно представленные в списке как одна, Мощный инструмент для такого анализа - концепция подтипов сущностей. Вернемся к примеру с ателье: покупка и заказ одежды представляют одно событие - приобретение мистером N одежды, однако это разные типы приобретения. Другими словами, продажа готовой одежды и заказ одежды будут являться подтипами сущности приобретение одежды.

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

на заказ).

Может оказаться, что некоторые подтипы сущностей обладают одинаковым наборов уто1>. Тогда лучше определить TypeOfSale (вид продажи), TyptOf€ustomer(тип клиента) и т. п. как атрибуты над-типа, а не моделировать подтипы как отдельные сущности. В примере с ателье для моделирования пошива одежды может оказаться необходимой информация о виде одежды и цвете, выбранном клиентом, г, для моделирования продажи готовые w/nnt - наименование фирмы - производителя одежды. В таком случае следует использовать подтипы для моделирования эти осте i г Однако если единственное, что вам нужно учитывать: была ли приобретена готовая одежда или сшитая на заказ, лучше ввести атрибут

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

Большинство сущностей моделируют объекты или события реального мира, примерами могут служить клиенты, товары, или звонки в службу продаж. Это конкретные сущности.

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

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

Вопрос, нужноли моделировать отношения, у которых отсутствуют атрибуты, как отдельные сущности, не столь тривиален. Лично я считаю, что, представляя подобные как отдельные сущ-

ности, вы ничего не выигрываете, в то как построение схемы

базы данных на основе модели данных существенно усложняется. И