Затонский А.В. Пособие по полному жизненному циклу информационных систем

Подождите немного. Документ загружается.

251

нижней части иерархии. Таким образом, «свиные уши», имеющие сторону с

обязательным участием, всегда некорректны.

Рис. 85. «Свиное ухо», имеющее сторону с обязательным участием

Неисключающие подтипы и невключающие cупертипы

Некоторые сущности при анализе разбиваются на подтипы. В этом случае

довольно просто спутать подтипы с членством в классах. Подтипами

называются атомарные сущности более сложной сущности (называемой

супертипом). Подтипы должны быть разделены между собой и в совокупности

образовывать супертип. Другими словами, подтипы должны быть

взаимоисключающими, и не может существовать экземпляр подтипа, не

принадлежащий супертипу. На рис. 86 приведен пример, взятый из

агрохимической промышленности, который нарушает эти правила.

Рис. 86. Неправильно созданные подтипы и супертип

Верно, что подавляющее большинство пестицидов можно отнести к

следующим классам: фунгициды (для борьбы с заболеваниями растений),

гербициды (для борьбы с сорняками), инсектициды (для уничтожения

насекомых) или родентициды (для убиения несчастных грызунов). Однако

существуют пестициды, имеющие двойное назначение, они, например, служат

и фунгицидами, и гербицидами. Далее, некоторые пестициды не являются ни

фунгицидами, ни гербицидами, ни инсектицидами, ни родентицидами — это,

например, регуляторы роста растений.

252

Таким образом, приведенная модель некорректна, потому что она не

соответствует ни одному из установленных нами правил: подтипы здесь не

являются взаимоисключающими, а супертип — не включающий.

Ясно, что для выполнения проверки необходимы определенные знания в

данной области. Если есть сомнения, обратитесь к аналитику или пользователю

(желательно получить независимые мнения обоих). Задайте им

соответствующие вопросы, например: «Есть ли сейчас или может на рынке в

будущем появиться пестицид для борьбы с двумя и более категориями

вредителей?» или «Предлагаются ли на рынке разные продукты в одинаковой

упаковке?»

Остерегайтесь относить сущность более чем к одной несвязанной

категории. Рассмотрим модель, описывающую пациентов в больнице (рис. 87).

Можно разделить их на стационарных и амбулаторных (медицинский персонал

особенно заинтересован в таком делении). С другой стороны, финансовый

отдел делит пациентов по-иному: на частных (оплачивающих свое лечение) и

государственных (которых лечат бесплатно).

Рис. 87. Супертип с подтипами двух категорий

Такое разделение пациентов на две группы вызывает ряд проблем, если

попытаться реализовать одну или обе эти категории в виде отдельных таблиц.

Попытка скомбинировать несвязанные категории, как на рис. 88, лишь

усугубит проблемы, опять-таки особенно при попытке реализовать эти

сущности в виде отдельных таблиц. Скажем только, что, в конце концов, вам,

скорее всего, придется решить, какая из категорий менее важна, и сделать ее

атрибутом. Иначе говоря, кто победит – медицинский персонал или

финансовый отдел.

253

Рис. 88. Комбинирование несвязанных подтипов

По сути дела, задача сводится к выбору: объединить подтипы в одну

таблицу или сделать их отдельными таблицами в базе данных? Чтобы выбор

стал очевидным, выполните следующие операции:

• установите, имеют ли все подтипы одинаковый первичный ключ;

• определите количества общих и индивидуальных атрибутов;

• определите количество отношений с подтипами и количество отношений

с супертипом.

Возьмем случай с пациентами из рис. 88 и рассмотрим типы

«стационарный пациент» и «амбулаторный пациент». Весьма вероятно, что

большинство атрибутов пациента будут регистрироваться независимо от того,

какой он – стационарный или амбулаторный. Могут иметь место отношения,

которые касаются только стационарных пациентов, например, место в палате.

Предположим, что нашей задачей является создание одной таблицы. Что же

нужно для этого сделать?

Добавим в таблицу «Пациенты» столбец «Тип пациента» для указания

того, какой это пациент – стационарный или амбулаторный. Чтобы в этом

столбце стояло только одно из этих двух значений, мы используем

ограничение. Для всех обязательных столбцов и внешних ключей, относящихся

к одному из данных подтипов, установим следующие ограничения: они не

должны быть неопределенными (NOT NULL). Кроме того, мы должны ввести

ограничения, обеспечивающие, Чтобы столбцы, относящиеся к определенному

подтипу, для других подтипов всегда были неопределенными (NULL).

Наконец, можно создать представления, которые покажут, как будут выглядеть

наши таблицы, если бы мы избрали вариант с раздельными таблицами. Эти

представления можно использовать в приложениях, которые работают только с

одним из подтипов.

Отношения «многие ко многим»

Отношения «многие ко многим» в концептуальной информационной

модели должны оставаться в неприкосновенности, но в логической модели мы

254

должны обработать и разрешить каждое из них. Сначала нужно проверить,

действительно ли данное отношение является отношением «многие ко

многим». Иногда такое отношение используется для представления временного

отношения. Этот случай иллюстрируется рис. 89. Между автомобилем и его

двигателем существует отношение «один к одному». Однако двигатель

автомобиля может быть заменен, а старый двигатель отремонтирован и

установлен на другой автомобиль. Конечно, ни одну из этих ситуаций нельзя

назвать правильной или неправильной – все зависит от того, должна ли система

регистрировать архивные данные.

Рис. 89. Статическое и временное представление одной и той же конструкции

Поскольку отношение «многие ко многим» нельзя непосредственно

реализовать в реляционной базе данных, оно разрешается с помощью новой

«сущности», размещаемой посередине. Так, пример на рис. 90 разрешается

путем создания новой сущности, показанной на рис. 91. Эту новую сущность

называют по-разному – связующей, ассоциативной или сущностью-

пересечением. На некоторой стадии вы, возможно, обнаружите, что связующая

сущность имеет собственные атрибуты. В нашем примере новая сущность JOB

TASK LINK может иметь важный атрибут – «Порядок задач», определяющий

порядок выполнения задачи (TASK) в пределах задания (JOB).

Рис. 90. Отношение «многие ко многим» между заданиями и задачами

Рис. 91. Разрешение отношения «многие ко многим» с помощью связующей

сущности

255

Связующая сущность не живет своей жизнью. По сути, если удалить одну

из сторон, то смысл существования этой сущности пропадет. Вам нужно

определить правила, например такие: если пользователь попытается удалить

сущность TASK, то он не сможет этого сделать, если у этой сущности есть одна

или несколько сущностей JOB TASK LINK или если это удаление каскадно

распространяется на все JOB TASK LINK. Это, скорее всего, не техническое, а

бизнес-решение (спросите аналитика или, еще лучше, квалифицированного

пользователя). Такие же факторы действуют при удалении задания.

Вывод

Реальным средством моделирования данных является не формальный

метод нормализации отношений, а так называемое семантическое

моделирование.

В качестве инструмента семантического моделирования используются

различные варианты диаграмм сущность-связь (ERD – Entity-Relationship

Diagram).

Диаграммы сущность-связь позволяют использовать наглядные

графические обозначения для моделирования сущностей и их взаимосвязей.

Различают концептуальные и физические ER-диаграммы.

Концептуальные диаграммы не учитывают особенностей конкретных СУБД.

Физические диаграммы строятся по концептуальным и представляют собой

прообраз конкретной базы данных. Сущности, определенные в концептуальной

диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при

этом учитываются допустимые для данной СУБД типы данных и наименования

столбцов), связи реализуются путем миграции ключевых атрибутов

родительских сущностей и создания внешних ключей.

При правильном определении сущностей, полученные таблицы будут

сразу находиться в 3НФ. Основное достоинство метода состоит в том, модель

строится методом последовательных уточнений первоначальных диаграмм.

Индексы и их использование

Рассмотрим проблемы, связанные с выбором ключей и индексов для

таблиц проектируемой базы данных. Индексы необходимы для достижения

хорошей производительности. Однако при проектировании индексам часто не

уделяется должное внимание, так как считается, что их можно создавать и

изменять в процессе тестирования или эксплуатации системы, когда станет

очевидно, что возникли проблемы с производительностью. В этих

рассуждениях есть доля правды, и не следует пытаться формулировать полную

стратегию индексирования на этапе проектирования. Опыт показывает, что это

неизбежно ведет к «перегрузке» индексами больших таблиц, что сопряжено со

значительными затратами на достижение нормальной производительности при

сохранении и обновлении [50].

Задача проектирования хорошего набора индексов очень сложна, требует

много времени и сопряжена с ошибками даже для рабочих нагрузок и баз

256

данных средней сложности. В разработке оптимальных индексов может помочь

понимание характеристик базы данных, запросов и столбцов данных.

При проектировании индекса следует учитывать следующие

рекомендации, связанные с базами данных

• Большое количество индексов в таблице снижает производительность

инструкций INSERT, UPDATE, DELETE и MERGE, потому что при

изменении данных в таблице все индексы должны быть изменены

соответствующим образом.

• Избегайте использования чрезмерного количества индексов для

интенсивно обновляемых таблиц и следите, чтобы индексы были узкими,

то есть содержали как можно меньше столбцов.

• Используйте большое количество индексов, чтобы улучшить

производительность запросов для таблиц с низкими требованиями к

обновлениям, но большими объемами данных. Большое число индексов

может повысить производительность запросов, которые не изменяют

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

запросов будет больший выбор индексов при определении самого

быстрого способа доступа.

• Индексирование маленьких таблиц может оказаться не лучшим выбором,

так как поиск данных в индексе может потребовать у оптимизатора

запросов больше времени, чем простой просмотр таблицы.

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

использоваться, но, тем не менее, их необходимо поддерживать при

изменении данных в таблице.

При проектировании индекса следует принимать во внимание следующие

рекомендации, связанные с обработкой запросов.

• Следует создавать индексы для всех столбцов, которые часто

используются в предикатах и условиях соединения в запросах. Однако

нужно избегать добавления столбцов без необходимости. Добавление

слишком большого числа индексных столбцов может отрицательно

повлиять на количество свободного места на диске и на

производительность поддержания индекса.

• Покрывающие индексы могут повысить производительность запросов,

так как данные, необходимые для удовлетворения требований запроса,

присутствуют в самом индексе. Таким образом, для получения

запрашиваемых данных требуются только страницы индекса, а не

страницы данных таблицы или кластеризованного индекса;

следовательно, уменьшается общий объем операций дискового ввода-

вывода. Например: запрос по столбцам a и b таблицы, у которой есть

составной индекс, созданный на основе столбцов a, b и c может найти

нужные данные, пользуясь только этим индексом.

• Запросы следует составлять так, чтобы они вставляли или изменяли как

можно больше строк одной инструкцией, вместо того, чтобы

использовать для обновления тех же строк нескольких запросов.

257

Используя только одну инструкцию, можно воспользоваться

возможностями, которые обеспечивает поддержание оптимизированного

индекса.

• Определите тип запроса и то, как в нем используются столбцы.

Например: столбец, который используется в запросе с точным

соответствием, может оказаться подходящим кандидатом для создания

индекса.

При проектировании индекса, следует принимать во внимание

следующие рекомендации, относящиеся к столбцам.

• Проверьте уникальность столбцов. Замена неуникального индекса

уникальным для той же комбинации столбцов обеспечивает

оптимизатору запросов дополнительные сведения, что делает индекс

более полезным.

• Проверьте распределение данных в столбце. Часто длительное

выполнение запроса обусловлено индексированием столбца, в котором

мало уникальных значений, или присоединением такого столбца. Это

фундаментальная проблема, связанная с данными и запросом, и обычно

она не может быть решена без определения ситуации. Например:

физический телефонный справочник, отсортированный в алфавитном

порядке по фамилии, не сможет быстро найти человека, если у многих

жителей города фамилии Иванов или Кузнецов.

• Следует учитывать порядок столбцов, если индекс будет включать их

несколько. Столбец, использованный в предложении WHERE в условии

поиска равных (=), больших (>), меньших (<) или находящихся в

интервале (BETWEEN) значений или участвующий в соединении, должен

стоять первым. Дополнительные столбцы должны быть упорядочены по

уровню различимости, то есть от наиболее четкого к наименее четкому.

Например, если индекс определен как LastName, FirstName, индекс будет

полезным, если критерий поиска — WHERE LastName = 'Smith' или

WHERE LastName = Smith AND FirstName LIKE 'J%'. Однако

оптимизатор запросов не станет использовать этот индекс для запроса

только по критерию FirstName (WHERE FirstName = 'Jane').

В случае если выбор индексов производится на стадии, когда статистика

будущих запросов и характер использования БД не определен окончательно,

можно воспользоваться следующими рекомендациями общего характера.

• Создавайте индексы на столбцах, которые часто используются в разделе

WHERE встроенных операторов SQL или запросов, используемых

конечными пользователями.

• Индексируйте столбцы, часто используемые в операторах SQL для

соединения таблиц.

• Используйте для индексирования только те столбцы, в которые входит

небольшой процент строк с одним и тем же значением.

• Не индексируйте столбцы, которые используются только в функциях и

операторах раздела WHERE запросов.

258

• Не индексируйте часто изменяемые столбцы, а также не применяйте

индексацию в тех случаях, когда повышение эффективности за счет

создания индекса приводит к снижению эффективности при выполнении

операций INSERT, UPDATE и DELETE. Выполнение этих операций

замедлится из-за необходимости поддерживать индексы.

• Уникальные индексы лучше неуникальных по причине их более высокой

селективности. Используйте уникальные индексы на столбцах

первичного ключа и неуникальные индексы на столбцах внешнего ключа

и столбцах, часто используемых в разделе WHERE.

• Создавайте индексы таким образом, чтобы столбцы, используемые в

разделе WHERE, составляли начальную группу столбцов в ключе

индекса.

Расчет заработной платы

Предметная область

Расчет зарплаты является ответственной и трудоемкой работой, которую

нужно выполнять в короткие сроки между предоставлением информации о

выработке работника и выплатами ему. В начале 1990-х годов главной задачей

при расчете зарплаты была интеграция расчетов в комплексную систему

бухгалтерского учета: рассчитать налоги, выдать сводные ведомости и

расчетно-платежную документацию. Теперь ситуация несколько изменилась:

из-за законодательных актов, принятых за последние годы, и роста объемов

отчетности автоматизация заработной платы превратилась в отдельную и

достаточно сложную проблему.

Во-первых, начисление зарплаты состоит из множества расчетов, каждый

из которых регулируется отдельными нормативными актами.

Во-вторых, расчет по заработной плате связан не только с

налогообложением, но и с индивидуальным пенсионным учетом, то есть с

отчислением средств на пенсионные счета граждан, открытые Пенсионным

фондом России. Эти взносы должны быть рассчитаны в процессе расчета

заработной платы, и все организации несут ответственность за правильность их

начисления и учета. А объемы и периодичность отчетности, требуемые

пенсионным законодательством, таковы, что расчет и учет заработной платы

теперь уже невозможен без пенсионного учета.

И, наконец, от расчетчика заработной платы требуется постоянная выдача

справок о заработке работника (не только справок о доходах для налоговой

службы, но и справок для предоставления жилищных компенсаций и справок

по месту требования). По всем вышеперечисленным особенностям учет труда и

заработной платы по праву занимает одно из центральных мест во всей системе

учета на предприятии.

Правильное ведение учета, своевременная сдача отчетности играют

значительную роль в жизни любого предприятия, ведь ошибки в учете могут

привести не только к недоплате, что повлечет за собой штрафы и пени, но

259

также и к их переплате. Немаловажным является и тот факт, что недостаточная

степень автоматизации учета ведет к снижению качества учета и отчетности,

производительности труда. Все это отрицательно сказывается на прибыльности

и репутации данного предприятия.

От предыдущих примеров эта задача отличается тем, что кроме

организации рационального хранения данных, быстрого поиска, контроля

целостности и достоверности денормализованных данных и т.п., создаваемые

модели должны обеспечить быстрое проведение объемного расчета. Расчет и

учет заработной платы и отчислений можно разделить на несколько не очень

сильно связанных подобластей (рис. 112).

Рис. 92. Укрупненная схема предметной области

Налоговый учет включает классификацию, подготовку, передачу

налоговой информации в соответствующие органы (инспекция федерального

агентства по налогам и сборам, пенсионный фонд и т.д.). В отличие от налога

на доходы физических лиц (НДФЛ), который оплачивается из дохода

работника, большинство налогов и сборов выплачиваются предприятием в

зависимости от размера фонда оплаты труда (ФОТ). Так, в настоящее время

НДФЛ составляет 13%, а нормальная ставка остальных налогов на ФОТ –

26.2%. Следовательно, с каждых 100 рублей заработной платы работника

предприятие выплатит 13.00 + 26.20 = 39.20, а реальная ставка налога на

доходы составляет 39.20 / 139.20 = 28.2%.

Справочник

начислений и

удержаний

Расчет заработной платы

Начисления

Удержания Налоги

Формирование

и хранение

документов

Штатное

расписание

Налоговый

учет и

четность

планово-экономический

отдел

отдел кадров

отдел труда и зарплаты

…

ИФНС

ФСС

ПФР

ФФОМС

ТФОМС

…

справка

свод

алименты

штрафы

…

Работники

260

Штатное расписание и учет кадров

Отдел кадров обеспечивает выполнение следующих функций: прием

сотрудника на работу, отслеживание его состояния в течение периода его

работы и, наконец, увольнение сотрудника с работы. Дополнительно, отдел

кадров должен формировать много отчетов перед бухгалтерией и внешними

организациями, например, Пенсионным фондом и статистическими органами.

Работа отдела кадров регламентирована законодательством (например, Законом

о труде) и коллективным договором. В частности, предопределены формы

приказов о приеме и увольнении, личные карточки сотрудников, формы

отчетов.

Имеется информация о функциях отдела кадров, основных входящих

(рис. 113) и исходящих документах (рис. 114).

Отдел кадров

Пенсионный фонд Бухгалтерия

Руководство

предприятия

Органы

статистики

1. «Любимые» отчеты

руководства

2. Отчеты

произвольной формы

1. Анкета

застрахованного лица

2. Индивидуальные

сведения

1. Сведения о принятых и уволенных

2. Сведения о среднесписочной

численности

Приказы:

1. О приеме

2. Об увольнении

3. О перемещении

4. Об отпуске

5. Информация о больничных

листах

Рис. 93. Примеры исходящих документов