пособие_ism

−общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности; не помечается каким-либо символом;

−символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);

−символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);

−цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.

Имя связи (Verb Phrase) – фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи «один-ко- многим», идентифицирующей или неидентифицирующей, достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указы-

вать имена как Parent-to-Child, так и Child-to-Parent.

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

Характеристическая – зависимая дочерняя сущность, которая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности (рисунок 5.36).

Рисунок 5.36 – Пример характеристической сущности «Хобби»

Ассоциативная – сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей.

Именующая – частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа).

Категориальная – дочерняя сущность в иерархии наследования. Иерархия наследования (или иерархия категорий) представляет

собой особый тип объединения сущностей, которые разделяют общие характеристики. Например, в организации работают служащие, занятые полный рабочий день (постоянные служащие), и совместители. Из их общих свойств можно сформировать обобщенную сущность (родовой предок) «Сотрудник» (рисунок 5.37), чтобы представить информацию, общую для всех типов служащих. Специфическая для каждого типа ин-

100

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

Обычно иерархию наследования создают, когда несколько сущностей имеют общие по смыслу атрибуты, либо когда сущности имеют общие по смыслу связи (например, если бы «Постоянный сотрудник» и «Совместитель» имели сходную по смыслу связь «работает в» с сущностью «Организация»), либо когда это диктуется бизнес-правилами.

Для каждой категории можно указать дискриминатор — атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой (атрибут «Тип» на рисунке 5.37).

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

Если категория еще не выстроена полностью и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках, то такая категория будет неполной. На рисунке 5.37 показана неполная категория – сотрудник может быть не только постоянным или совместителем, но и консультантом, однако сущность «Консультант» еще не внесена в иерархию наследования.

Рисунок 5.37 – Иерархия наследования. Неполная категория

101

Рисунок 5.38 – Иерархия наследования. Полная категория

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

Первичный ключ (primary key) — это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности. атрибуты первичного ключа на диаграмме не требуют специального обозначения

— это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии (см., например, рисунок 5.38).

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

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

Рассмотрим кандидатов на роль первичного ключа сущности «Сотрудник» (рисунок 5.39).

Рисунок 5.39 – Определение первичного ключа для сущности "Сотрудник"

Здесь можно выделить следующие потенциальные ключи:

102

−табельный номер;

−номер паспорта;

−фамилия + имя + отчество.

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

Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа. потенциальный ключ № 3 (Фамилия + Имя + Отчество) является плохим кандидатом, поскольку в организации могут работать полные тезки.

Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности. Для обеспечения уникальности ключа № 3 дополним его атрибутами Дата рождения и Цвет волос. Если бизнес-правила говорят, что сочетания атрибутов Фамилия + Имя + Отчество + Дата рождения достаточно для однозначной идентификации сотрудника, то Цвет волос оказывается лишним, т. е. ключ Фамилия + Имя + Отчество + Дата рождения + Цвет волос не является компактным.

Рисунок 5.40 – Пример логической модели данных

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

103

атрибутов. В приведенном примере ключи № 1 и 2 предпочтительней ключа № 3.

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

Каждая сущность должна иметь по крайней мере один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные — альтернативными ключами.

Рисунок 5.41 – Пример физической модели данных

Альтернативный ключ (Alternate Key) — это потенциальный ключ, не ставший первичным.

Нормализация данных. Нормализация данных — процесс про-

верки и реорганизации сущностей и атрибутов с целью удовлетворе-

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

104

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

На практике обычно ограничиваются приведением данных к третьей нормальной форме. Примеры логической и физической моделей, соответствующих основным требованиям третьей нормальной формы, приведены на рисунках 5.40 и 5.41. ERwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных имен атрибутов в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила "один факт – в одном месте". Имена ролей атрибутов внешних ключей и унификация атрибутов также облегчают построение нормализованной модели.

5.5 Выбор СУБД

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

Выбранная СУБД может поддерживать как архитектуру «клиент-

сервер» (Microsoft SQL Server, InterBase, Sybase Adaptive Server Anywhere и т.п.), так и архитектуру «файл-сервер» (Microsoft Access, Microsoft Visual FoxPro и т.п.).

105

6 ЗАЩИТА КУРСОВОЙ РАБОТЫ

6.1 Общий порядок защиты курсовой работы

К защите курсовой работы допускаются студенты, выполнившие курсовую работу в полном объеме, о чем свидетельствует записка по курсовой работе, подписанная руководителем курсовой работы. Оформление записки должно соответствовать требованиям НТУ «ХПИ». Основные выводы руководителя о соответствии содержания курсовой работы заданию, степени самостоятельности выполнения курсовой работы и т.д. должны быть отражены в отзыве руководителя.

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

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

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

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

6.2 Требования к презентационным материалам

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

Примерный перечень презентационных материалов (плакатов).

1.Постановка задачи исследования.

2.Общая характеристика предметной области.

3.Примеры моделей IDEF0.

4.Примеры моделей IDEF3.

5.Примеры моделей DFD.

6.Модель данных (логическая и/или физическая).

7.Схема данных, реализованная средствами выбранной СУБД.

8.Материалы, дающие представление о разработанном прикладном программном обеспечении и иллюстрирующие результаты его работы – запросы, отчетные формы, графики, диаграммы и т.п.

106

Общее количество презентационных материалов (плакатов) – 7-8. Презентационные материалы могут быть выполнены в бумажном или электронном виде. Бумажные презентационные материалы выпол-

няются на бумаге формата А4 в машинописном виде (т.е. должны быть напечатаны на лазерном или струйном принтере). Все надписи и рисунки должны быть четкими, хорошо читаться. Рукописный вариант презентационных материалов не допускается. Электронные презентационные материалы выполняются с использованием соответствующего программного обеспечения (Microsoft Power Point и т.п.) и демонстрируются с помощью компьютера.

6.3 Требования к докладу

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

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

6.4 Требования к демонстрации программного обеспечения

Основная задача демонстрации программного обеспечения – показать работоспособность разработанного программного обеспечения, его основные функциональные возможности, удобство работы пользователя и т.д. Студент должен показать свое умение работать с программным обеспечением, а при необходимости продемонстрировать, каким образом программное обеспечение может быть модифицировано.

107

7 КРИТЕРИИ ОЦЕНИВАНИЯ КУРСОВОЙ РАБОТЫ

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

−актуальность темы выполняемой работы;

−степень самостоятельности выполнения работы студентом;

−основные результаты, полученные при выполнении работы;

−оценка работы по пятибалльной шкале.

Кроме того, на оценку оказывают влияние следующие факторы.

1.Наличие ошибок и неточностей при построении моделей биз- нес-процессов и моделей данных, а именно:

1)несоответствие разработанных моделей и реализованной базы данных выбранной предметной области;

2)неполное отражение в модели данных особенностей предметной области, в результате чего модель данных не является адекватной задаче, решаемой в курсовой работе;

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

2.Ошибки, сбои и т.п. в работе прикладного программного обеспечения, выявленные при его демонстрации в процессе защиты курсовой работы.

3.Некачественная подготовка доклада студентом.

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

5.Небрежное оформление пояснительной записки – нарушение требований к оформлению, наличие большого числа исправлений, грамматические и другие ошибки и т.п.

108

8 СПИСОК ИСТОЧНИКОВ ИНФОРМАЦИИ

1.Бондаренко М.Ф., Маторин С.И., Соловьева Е.А. Моделирование и проектирование бизнес-систем: методы, стандарты, технологии: Учебное пособие. – Харьков: Компания СМИТ, 2004. – 272 с.

2.Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и стати-

стика, 2000. – 352 с.

3.Гужва В.М. Інформаційні системи і технології на підприємствах. – К.: КНЕУ, 2001. – 400 с.

4.Дейт, К. Дж. Введение в системы баз данных : Пер. с англ. – 6-е изд. – К.: Диалектика, 1998. – 784 с.

5.Елиферов В.Г., Репин В.В. Бизнес-процессы: регламентация и управление: Учебник. – М.: ИНФРА-М, 2005. – 319 с.

6.Калянов Г.Н. CASE-технологии. Консалтинг при автоматизации бизнес-процессов. – М.: Горячая линия–Телеком, 2000. – 320 с.

7.Когаловский М.Р. Энциклопедия технологий баз данных. – М.: Финансы и статистика, 2002. – 800 с.

8.Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2001. – 1120 с.

9.Маклаков С.В. BPWin и ERWin. CASE-средства разработки информационных систем. – 2-е изд., испр. и дополн. – М.: ДИАЛОГ-

МИФИ, 2001. – 304 с.

10.Маклаков С.В. Моделирование бизнес-процессов с AllFusion Process Modeler (BPWin 4.1). – М.: ДИАЛОГ-МИФИ, 2003. – 240 с.

11.Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. – М.: ДИАЛОГ-МИФИ, 2003. – 432 с.

12.Проектирование экономических информационных систем: Учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; Под ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2001. – 512 с.

13.Ротер М. Учитесь видеть бизнес-процессы. Практика построения карт потоков создания ценности : Пер. с англ. – М.: Альпина Бизнес Букс: CBSD, Центр развития деловых навыков, 2005. – 144 с.

14.Тельнов Ю.Ф. Реинжиниринг бизнес-процессов. Компонентная методология. – 2-е изд., перераб. и доп. – М.: Финансы и статистика, 2004. – 320 с.

15.Устинова Г.М. Информационные системы менеджмента: Основные аналитические технологии в поддержке принятия решений / Учеб. пособие. – СПб.: Издательство «ДиаСофтЮП», 2000. – 368 с.

109