Системы управления базами данных

Министерство образования Российской Федерации

Кузнецкий институт информационных и управленческих технологий

Системы управления базами данных

Методические указания

к курсовым работам

Кузнецк 2008

ERwin - CASE-средство моделирования баз данных для профессиональных разработчиков

Семейство продуктов ERwin фирмы PLATINUM - CA (США) относится к мощным персональным CASE-продуктам, предназначенным для моделирования баз данных самого различного типа. Отличительной чертой продуктов ERwin является высокая степень обеспечения согласованного взаимодействия между средствами создания баз данных и средствами разработки приложений в технологии клиент-сервер.

ERwin является наиболее популярным пакетом моделирования данных среди профессиональных разработчиков благодаря полной поддержке широкого спектра СУБД самого разного класса, включая Oracle, DB/2, Sybase, Informix, MS SQL Server, SQLBase, CA Ingres, Rdb, AS/400, Progress, Interbase, Watcom, в том числе: Clipper, dBase, Access, Fox, Paradox.

CASE-средство ERwin предназначено для разработчиков, проектировщиков БД, системных аналитиков для построения модели данных в процессе разработки технического проекта информационной системы. С помощью ERwin разработчик может, используя визуальные средства, описать логическую модель данных. На основе логической модели создается физическая модель для конкретной СУБД с использованием хранимых процедур и триггеров. Результатом работы по созданию физической модели может стать генерация структуры базы данных.

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

Методологическую основу ERwin составляет технология IDEF1X ( моделирование данных для реляционных СУБД ). Результатом построения является ER-диаграмма ("сущность-связь"). Графический подход к созданию моделей значительно упрощает процесс разработки.

Основные характеристики

Поддержка стандартной нотации IDEF1X для ER диаграмм моделей данных и нотации IE. Специальные реализации продукта с прямой поддержкой расширенного набора атрибутов в моделях данных для средств разработки приложений SQLWindows, PowerBuilder, Oracle*CASE, Visual Basic, Progress. Существуют линки для работы с Delphi и Centura Team Developer от третьих производителей. Возможность импорта/экспорта данных из BРwin, Oracle Designer. Автоматическая генерация баз данных для широкого спектра целевых СУБД (Сentura SQLBase, Oracle, Informix, Sybase, Progress, Ingres, Microsoft SQLServer и др.) Поддержка проектирования информационных хранилищ (на основе Red Brick) Поддержка совместного проектирования (версия для ModelMart) Поддержка триггеров, хранимых процедур и шаблонов Развитые средства проверки корректности моделей данных Reverse Engineering (генерация модели данных на основе анализа существующей базы данных), включая восстановление связей по индексам Автоматическая генерация SQL DDL для создания баз данных Полная совместимость и поддержка Oracle, Sybase, Informix, SQLBase и др. (более 20-ти типов СУБД) на основе прямого доступа к системному каталогу баз данных (отпадает потребность в использовании ODBC) Глубокая интеграция с технологией и продуктами фирм Oracle, Sybase, Centura, Microsoft на базе единого репозитория и эффективного обмена проектами; импорт/экспорт с Rational Rose (объектно-ориентированное средство проектирования информационных систем в стандарте UML) Автоматическая генерация экранных форм приложений для SQLWindows, PowerBuilder, Delphi, Visual Basic, Progress (Progress Software лицензировала ERwin как одно из самых лучших CASE-средств в мире) созданных на основе спроектированной модели данных.

ERwin позволяет проектировать, документировать и сопровождать базы данных, хранилища данных и витрины данных (data marts). Создав наглядную модель базы данных, пакет позволяет оптимизировать структуру БД и добиться ее полного соответствия требованиям и задачам организации. Визуальное моделирование повышает качество создаваемой базы данных, продуктивность и скорость ее разработки.

1 Уровни представления данных

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

Известно, что одна и та же информация о предметной области может быть представлена различными способами. Рассмотрим уровни представления данных более подробно.

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

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

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

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

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

Концептуальное представление системно независимо, т. е. независимо от конкретной СУБД, операционной системы и аппаратного обеспечения ЭВМ.

Следующий уровень представления данных - это представление в терминах конкретной СУБД. Все современные СУБД поддерживают определенный тип модели данных, в основном сетевой, иерархический или реляционный.

Описание предметной области в терминах модели данных, поддерживаемой конкретной СУБД, называется логическим представлением.

И последний уровень представления данных - это внутреннее представление.

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

Уровни представления информации приведены на рис. 1.

…

Рис. 1 Уровни представления данных

2 Построение концептуальной модели предметной области

В большинстве предлагаемых методик основным действующим лицом процесса описания предметной области является профессиональный проектировщик или группа проектировщиков. На этапе построения концептуальной модели предметной области (КМПО) проектировщик выполняет следующие задачи:

1.  Выявляет цели, которые преследует администрация предприятия, принимая решение о создании информационной системы.

2.  Выделяет на основе этих целей потенциальных пользователей системы.

3. Интервьюирует пользователей и создает внешние пользовательские представления

Эти шаги состоят в определении информационных потребностей базы данных. Они

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

§  сможет ли новая система объединить существующие приложения или их

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

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

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

§  кто будет вводить данные в базу, и в какой форме; как часто будут изменяться

данные;

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

несколько баз данных с различными структурами;

§  каждая информация является наиболее чувствительной к скорости ее извлечения и

изменения.

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

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

§  идентификацию функциональной заданной деятельности предметной области

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

§  идентификацию объектов, которые осуществляют эту функциональную деятель-

ность, и формирование из их операций последовательности событий, которые помогут идентифицировать все сущности и взаимосвязи между ними (например, процесс "ведение учета работающих” идентифицирует такие сущности, как РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ),

§  идентификацию характеристик этих сущностей (например, сущность РАБОТНИК

может включать такие характеристики, как Идентификатор Работника, Фамилия, Имя, Отчество, Профессия, Зарплата);

§  идентификацию взаимосвязей между сущностями (например, каким образом

сущности РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ взаимодействуют друг с другом? Работник имеет одну профессию и значится в одном отделе, в то время как в одном отделе может находиться много работников).

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

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

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

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

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

-  Она должна быть простой в использовании.

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

-  Такая модель должна обеспечивать естественность информационного моделирования.

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

3 Методология инфологического проектирования IDEF1X

Методология IDEF1X была разработана для ВВС США и теперь используется, в частности, в правительственных, аэрокосмических и финансовых учреждениях, а также в большом числе частных компаний.

В декабре 1993 года лаборатория компьютерных систем Национального института стандартов и технологии определила IDEFIX как стандарт моделирования данных.

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

3.1 Основные элементы lDEFlX-диаграммы

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

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

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

Связь – это функциональная зависимость между сущностями. Например, СЛУЖАЩИЙ совершает ПРОДАЖИ.

Каждая сущность обладает атрибутами. Атрибут - это свойство объекта, характеризующее его экземпляр. Сущность СЛУЖАЩИЙ может иметь атрибуты Имя, Дата рождения и т. д.

3.2 Построение инфологической модели

Процесс построения инфологической модели состоит из следующих шагов:

- определение сущностей;

- определение зависимостей между сущностями;

-  задание первичных и альтернативных ключей;

-  определение атрибутов сущностей;

-  приведение модели к требуемому уровню нормальной формы.

3.2.1 Определение сущностей

Первый шаг моделирования - извлечение информации из интервью и выделение сущностей.

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

-  иметь уникальное имя, и к одному и тому же имени должка всегда применяться одна и та же интерпретация. Одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;

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

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

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

На диаграмме сущность изображается прямоугольником (рис. 2). Прямоугольник может содержать имя сущности, ее описание, список ее атрибутов и другие сведения.

Рис. 2 Пример изображения сущности

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

Следующим шагом моделирования является идентификация атрибутов.

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

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

Каждая сущность должна обладать хотя бы одним возможным ключом.

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

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

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

Существует два правила зависимости.

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

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

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

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

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

-  уникальным образом идентифицировать экземпляр сущности;

-  не использовать неопределенные (NULL) значения;

-  не изменяться со временем (экземпляр идентифицируется с помощью ключа. При изменении ключа соответственно меняется экземпляр сущности);

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

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

Сущности, как правило, соответствует таблица в реальной СУБД.

Сущность является независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями (сущность СЛУЖАЩИЙ на рис. 3).

Сущность называется зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (сущность ДЕТИ на рис, 3).

Рис. 3 Пример зависимости и независимости сущности

Экземпляры независимой сущности могут быть уникально идентифицированы без определения ее связей с другими сущностями.

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

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

3.2.2 Определение зависимостей между сущностями

Следующим шагом моделирования является идентификация связей.

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

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

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

Например, важно знать фамилию сотрудника, и не менее важно знать, в каком отделе он работает. Таким образом, между сущностями ОТДЕЛ и СОТРУДНИК существует связь Состоит из (отдел состоит из сотрудников).

Связь - это понятие логического уровня, которому соответствует внешний ключ на физическом уровне.

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

Идентифицирующая связь изображается сплошной линией. Линии заканчиваются точкой со стороны дочерней сущности.

Связь "является родителем" (см. рис. 3) между сущностями СЛУЖАЩИЙ и ДЕТИ является идентифицирующей.

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

Рис. 4 Пример не идентифицирующей связи

Не идентифицирующая связь изображается пунктирной линией. Линии заканчиваются точкой со стороны дочерней сущности.

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

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

На IDEFlX-диаграмме могут быть определены следующие мощности связей:

-  каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;

-  каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

-  каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

-  каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

Допустимые варианты указания мощности приведены на рис. 5.

 

Z

Ноль, один или более Ноль или один

P N

Один или более В точности N

Рис. 5 Допустимые Варианты указания мощности связей

3.2.3 Определение альтернативных ключей

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

Например, для сущности ГРУППА каждый из атрибутов ФИО_старосты и ФИО_куратора может являться альтернативным ключом.

Для альтернативного ключа, как и для первичного, должны создаваться индексы при генерации БД.

3.2.4. Связи категоризации

Некоторые сущности определяют целую категорию объектов одного типа. В IDEF1X в таком случае создается сущность для определения категории и для каждого элемента категории, а затем вводится для них связь категоризации. Родительская сущность категории называется супертипом, а дочерние - подтипом (рис. 6),

Например, сущность СОТРУДНИК может содержать данные как о преподавателях, так и об инженерах. Первые и вторые имеют различные, частично пересекающиеся наборы атрибутов (минимальное пересечение подтипов составляет первичный ключ). Общая часть этих атрибутов (табельный номер, ФИО, адрес, телефон, дата рождения), включая первичный ключ, помещается в сущность-супертип СОТРУДНИК. Различная часть (например стаж преподавания для преподавателя и стаж работы для инженера и т. п.) помещается в сущности-подтипы.

В сущности–супертипа вводится атрибут-дискриминатора (например, Тип_ служащего), позволяющий различать конкретные экземпляры сущности-подтипа.

Рис. 6 Пример связи неполной категоризации

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

Рассмотренная на рис. 6 связь является связью неполной категоризации.

Если же супертип СЛУЖАЩИЙ содержит данные о прочих служащих, то это связь полной категоризации (рис. 7).

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

Рис.7 Пример связи полной категоризации

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

Система ERwin предназначена для автоматизации проектирования концептуальной модели предметной области согласно методологии IDEF1X.

После запуска на экране появляется основное окно системы (рис. 8), в котором и строится IDEFlX-диаграмма.

Рис. 8 Окно системы ERwin

Процесс построения информационной модели состоит из следующих шагов:

- определение сущностей;

- определение зависимостей между сущностями;

-  задание первичных и альтернативных ключей;

-  определение атрибутов сущностей;

-  приведение модели к требуемому уровню нормальной формы.

3.3.1 Создание сущностей и связей между ними

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

Рассмотрим создание диаграммы с помощью панели инструментов ERwin Toolbox (рис. 9). С помощью этого окна можно создать независимые и зависимые сущности, идентифицирующие и не идентифицирующие связи, полные и неполные категории, неспецифические связи и текстовые элементы.

Рис. 9 Панель ERwin Toolbox

Рассмотрим кнопки панели более подробно (нумерация кнопок слева направо и сверху вниз).

Кнопка 1.1 (стрелка) используется для перехода в режим выбора пунктов меню или объектов диаграммы для копирования, удалений или редактирования.

Кнопка 2.1 (рука) копирует или перемещает один или более выбранных атрибутов из одной сущности в другую или в пределах той же самой сущности.

В данном режиме вы можете:

-  изменить положение одного ключевого атрибута или группы ключевых атрибутов внутри одной сущности;

-  изменить положение одного не ключевого атрибута или группы не ключевых атрибутов внутри одной сущности;

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

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

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

Для выделения группы атрибутов, в сущности, используется мышь в сочетании с клавишами Ctrl или Shift.

По умолчанию осуществляется перенос атрибутов из одной сущности в другую.

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

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

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

Для задания размеров прямоугольника сущности используется команда Entity Size... из пункта основного меню Option. В результате на экране появится диалоговый блок, в котором можно определить высоту и ширину прямоугольника сущности. Практическое значение имеет только ширина прямоугольника.

Для определения цвета и шрифтов объектов диаграммы служит команда Default Font/Color… из пункта основного меню Option. В результате на экране появится диалоговый блок, в котором можно определить цвета и шрифты для сущностей, связей, ключевых и не ключевых атрибутов и т. п.

В качестве шрифта, поддерживающего кириллицу, можно предложить шрифт TimesET.

Кнопка 2.2 (прямоугольник с закругленными краями) применяется для добавления в диаграмму новой зависимой сущности. .

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

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

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

Кнопка 1.4 (сплошная линия с точкой на конце) применяется для определения между

двумя сущностями идентифицирующей связи.

Кнопка 2.4 (пунктирная линия с точкой на конце) служит для определения между двумя сущностями не идентифицирующей связи.

Кнопка 1.5 (сплошная линия с точками на обоих концах) используется для определения между двумя сущностями связи “многие-комногие”.

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

3.3.2 Определение атрибутов

Для занесения в сущность принадлежащих ей атрибутов необходимо щелкнуть на данном сущности правой кнопкой мыши и во всплывающем меню выбрать команду Entity-Attribute. В результате на экране появляется диалоговый блок редактора атрибутов сущности Entity-Attribute Editor (рис. 10).

В окне Primary Key вводятся ключевые атрибуты сущности. Не ключевые атрибуты вводятся в окне Non-Key Attributes. Для не ключевого атрибута, являющегося альтернативным ключом, справа добавляется обозначение (АК).

Рис. 10 Диалоговое окно описания атрибутов сущности

3.3.3 Определение характеристик связи

Для определения характеристик связи между двумя сущностями необходимо щелкнуть правой кнопкой мыши на линии связи и во всплывающем меню выбрать команду Relationship. В результате на экране появляется диалоговый блок (рис, 11), в котором можно задать наименование связи (окно Verb Phrase), ее тип {панель радиокнопок Relationship Type), указать мощность связи (панель радиокнопок Cfrdinaly).

3.3.4 Другие возможности системы ERwin

Команда Show Display Menu из пункта главного меню Option позволяет добавить или удалить пункт Display в главное меню системы.

Команда Show Editor Menu из пункта главного меню Option позволяет добавить или удалить пункт Editor в главное меню системы.

Рассмотрим более подробно некоторые полезные команды главного меню Display.

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

-  Entity Level - уровень сущностей. На диаграмме отображаются только сущности н взаимосвязи между ними.

- 

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

Рис. 11 Диалоговое окно определения характеристик связи

-  Primary Key Level позволяет отображать внутри сущностей только ключевые атрибуты.

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

Задать краткие аннотации можно командой Entity Definition всплывающего меню сущностей (вызывается с помощью правой кнопки мыши). В результате на экране появляется диалоговый блок Entity Definition Editor. В окне Definition этого блока и вводится краткое определение назначения текущей сущности.

-  Icon Level позволяет отображать на диаграмме только сущности. Внутри каждой из сущностей может находиться иконка, представляющая собой точечный рисунок. Связать каждую сущность файлом рисунка можно в том же диалоговом блоке Entity Definition Editor с помощью кнопки Bitmap...

-  Zoom позволяет увеличивать или уменьшать изображение диаграммы в окне системы.

-  Verb Phrase позволяет показать или скрыть надписи названий связей между сущностями на диаграмме.

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

-  Alternate Key позволяет показать или скрыть обозначение ( АК) для альтернативных ключей.

3.3.5 Пример построения IDEFlX-диаграммы

В качестве примера построения IDEFlX-диаграммы рассмотрим задачу проектирования концептуальной модели для предметной области “РАСПИСАНИЕ” (рис.12).

Рис. 12. Пример IDEF1X-диаграммы.

4. Логическое проектирование

4.1. Обоснование необходимости нормализации.

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

Отношения, допустимые в реляционной модели, должны удовлетворять следующему условию.

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

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

Отношение, удовлетворяющее приведенному выше условию, называется нормализованным.

Ненормализованное отношение достаточно просто преобразуется в эквивалентное нормализованное. Рассмотрим этот процесс на примере. Пусть имеется отношение:

СОТРУДНИК(Фамилия, Адрес),

содержащее кортежи

Петров Пенза, Кирова, 32, 5

Сидоров Пенза, Калинина, 22, 31

Из отношения видно, что атрибут Адрес содержит для каждого сотрудника город, улицу, дом и квартиру его места проживания.

В принципе понятие атомарности атрибута - понятие субъективное. Только проектировщик может определить - атомарный данный атрибут или нет.

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

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

СОТРУДНИК(Фамилия, Город, Улица, Дом, Квартира).

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

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

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

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

-  выбранные для отношений первичные ключи должны быть минимальными;

-  выбранный состав отношений базы данных должен быть минимальным (отличаться минимально избыточностью атрибутов);

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

-  перестройка набора отношений при введение новых типов данных должна быть минимальной;

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

Рассмотрим более подробно те трудности (аномалии), которые возникают при выполнении операций включения, удаления и модификации данных в “неправильном” проекте базы данных.

В качестве примера рассмотрим схему отношения

СОТРУДНИК (ФИО, Кафедра, ФИО_Зав_Каф, Должность)

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

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

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

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

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

Аномалия удаления. Когда увольняется последний сотрудник некоторой кафедры, автоматически теряются сведения и о самой кафедре.

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

В приведенном выше примере можно избавиться от аномалий путем разбиения исходной схемы СОТРУДНИК на две схемы СОТРУДНИК И КАФЕДРА,

СОТРУДНИК (ФИО, Должность, Наз_Кафедры)

КАФЕДРА (Наз_Кафедры, ФИО_Зав_Каф).

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

4.2 Нормальные формы отношений

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

Определение 1. Схема отношения R находится в первой нормальной форме (1НФ), если значения в dom (A) (dom (A) - область значений атрибута А, домен значений) являются атомарными для каждого атрибута А в R.

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

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

Определение 2. Схема базы данных находится в 1НФ, если каждая схема отношения в этой базе данных находится в 1НФ

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

Определение 3. Для данного множества функциональных зависимостей F и зависимостей X→Y € F+ множество Y называется частично зависимым от X относительно F, если существует X' X такой, что зависимость X’ →Y € F+.

В противном случае говорят, что Y полностью зависит от X.

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

С другой стороны, в зависимости Студент, Преподаватель→Тема_КП (тема курсового проекта) атрибут Тема_КП полностью зависит от левой части зависимости.

Определение 4. Для данной схемы отношения R, атрибута А в R и множества функциональных зависимостей F на R атрибут А называется первичным в R относительно F, если А содержится в каком-либо ключе схемы R.

В противном случае атрибут А называется не первичным в R

В различных схемах один и тот же атрибут может быть как первичным, так и не первичным. Так атрибут Группа является первичным в отношении ЗАНЯТИЕ, так как входит в ключ Ауд., Пара, N_Недели, Группа, и не первичным в отношении СТУДЕНТ.

Определение 5. Схема отношения R находится во второй нормальной форме (2НФ) относительно множества функциональных зависимостей F, если она находится в 1НФ а каждый не первичный атрибут полностью зависит от каждого ключа для R.

Схема базы данных имеет вторую нормальную форму относительно F, если каждая схема отношения в этой базе данных находится во 2НФ относительно F.

Определение 6. Для данной схемы отношения R, подмножества X множества R, атрибута А в R и множества функциональных зависимостей F атрибут А называется транзитивно зависимым от X в R, если существует подмножество YR такое, что X→Y, Y→X, Y→A относительно F и AXY.

Так, в функциональной зависимости Студент→Группа, Специальность, атрибут Специальность транзитивно зависит от атрибута Студент, так как существуют зависимости Студент→Группа, Группа→Студент и Группа→Специальность.

Определение 7. Схема отношения R находится в третьей нормальной форме (ЗНФ) относительно множества функциональных зависимостей F, если она находится в 1НФ и ни один из непривычных атрибутов в R не является транзитивно зависимым от ключа для R.

Схема базы данных находится в третьей нормальной форме относительно F, если каждая схема отношения находится в 3НФ относительно F.

Тогда схема базы данных, содержащая одно отношение R= {Студент, Группа, Специальность), не находится в 3НФ. В 3НФ находится схема базы данных, содержащая две схемы отношения R1={Студент, Группа} и R2={Группа, Специальность}.

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

Рассмотрим алгоритм приведения схем отношений к 3НФ путем декомпозиции.

4.3 Нормализация через декомпозицию

Нормализация через декомпозицию основана на рассмотренном нами выше определении 3НФ. Всегда можно взять некоторую схему отношения R, не находящуюся в 3НФ относительно множества функциональных зависимостей F, и разложить (декомпозировать) ее в схему базы данных, имеющую 3НФ относительно F.

Разложение (декомпозиция) схемы отношения R означает разбиение ее на пару схем отношений r1 и R2 так, чтобы любое отношение r(R), удовлетворяющее F, разлагалось без потерь на R1 и Я2, другими словами, соединение отношений r1 и R2 вновь давало бы отношение R, т. е.

R=∏R1(r)∏R2(r)

Если какое-либо из отношений R1 и R2 не находится в 3НФ, то процесс декомпозиции продолжается до тех пор, пока все полученные отношения не будут находиться в 3НФ относительно F.

Пусть имеется отношение R, в котором существует транзитивная зависимость не первичного атрибута от ключа, т. е. имеется ключ KR, множество YR и не первичный атрибут A в R, такие, что K→Y, Y→K, Y→A относительноF и A KY. Тогда схему R можно разложить на две схемы R1 и R2, где R1=R-A и R2=YA.

В r1 ключом будет множество К, в R2 - множество Y.

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

Процесс декомпозиции можно ускорить, проверяя наличие каких-либо других не первичных атрибутов в R-(KY), зависящих отY.

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

Предположим, А1, А2, …,Аm находим R-(KY) и зависит от Y. Тогда R1=R-(A1, A2, …Am) и R2=YA1, A2, …, Am.

Рассмотрим процесс нормализации через декомпозицию на следующем примере: не R={ФИО_Ст, Г_Р, Группа, Староста, Кафедра, ФИО_ЗК, Телефон}

F={ФИО_Ст→Г_Р, Группа, Кафедра;

Группа→Староста, Кафедра;

Кафедра→ФИО_ЗК, Телефон}

K=ФИО_Ст.

Так как ФИО_Ст→Кафедра, Кафедра→ФИО_ЗК, Телефон, то атрибуты ФИО_ЗК, Телефон транзитивно зависят от ключа ФИО_Ст. Поэтому разбиваем отношение R на

R1={ФИО Ст, Г_Р, Группа, Староста, Кафедра };

R2={Кафедра, ФИО_ЗК, Телефон}.

Заметим, что атрибут Кафедра остается и в отношение R1, и в отношении R2. Именно этот атрибут позволит нам не потерять информацию при декомпозиции, так как

Отношение R2 находится в 3НФ, что нельзя сказать об отношении R1. В отношении R1 ФИО_Ст→Группа, Группа→Староста. Кафедра.

Тогда отношение R1 необходимо декомпозировать на отношения R11 и R12:

R11={ФИО Ст, Г_Р, Группа}

R12={Группа, Староста, Кафедра},

которые находятся в 3НФ, и

В приложении А рассматривается пример построения IDEF1X-диаграммы и схем отношений в третьей нормальной форме.

Приложение А

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

Построение инфологической модели предметной области

Таблица сущностей.

Название сущности	Количество	Изменение количества сущностей	Идентификатор	Ограничение доступа	Тип связи
Кафедра	40	1%	Kafedra	Зав. каф., декан	1:М (Сотрудник) 1:М (Специальность)
Сотрудник	900	5%	Sotrudn	Зав. каф.	1:1 (Преподаватель) 1:1 (Инженер) М:1 (Кафедра)
Преподаватели	600	4%	Prepod	Зав. каф	1:1 (Сотрудник) 1:М (Расписание)
Инженеры	300	6%	Ingener	Зав. каф	1:1 (Сотрудник)
Расписание	800	100%	Raspis	Зав. каф., декан	1:1 (Преподаватель) 1:1 (Группа)
Специальность	50	2%	Spec	Зав. каф	1:1 (Кафедра) 1:1 (Группа)
Группа	300	20%	Gruppa	Зав. каф., декан	1:1 (Специальность) 1:М (Расписание)

Примечание.

Название сущности – название выделенной в предметной области сущности.

Количество – предлагаемое количество экземпляров сущности.

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

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

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

Тип связи – тип связи для каждой сущности, с которой связана данная сущность.

Таблицы атрибутов

В рассмотренном ниже примере приведены таблицы атрибутов только для двух сущностей: КАФЕДРА и СОТРУДНИК.

Таблица атрибутов сущности КАФЕДРА

Имя атрибута	Формат	Область допустимых значений	Ограничение доступа	Роль атрибута
Название каф.	Симв. 30		Зав. каф., декан	Ключ
ФИО_зав. каф.	Симв. 35		Зав. каф., декан	Возможный ключ
Телефон	Числ. 6	99	Зав. каф., декан
Выпускающая?	Лог. 1	Да/Нет	Зав. каф., декан

Таблица атрибутов сущности СОТРУДНИК

Имя атрибута	Формат	Область допустимых значении	Ограничение доступа	Роль атрибута
Таб. номер	Часл. 4	0-9999	Зав. каф.	Ключ
Название каф.	Симв. 30		Зав. каф.	Атрибут для связки
ФИО	Симв.35		Зав. каф.

Список запросов

1.  По фамилии заведующего кафедрой выдать список ее сотрудников.

2.  По фамилии сотрудника выдать фамилию заведующего кафедрой.

3.  По номеру специальности выдать телефон выпускающей кафедры.

4.  По названию кафедры выдать ученую степень и ученое звание всех ее преподавателей.

5.  По фамилии заведующего кафедрой выдать фамилии старост и кураторов групп.

6.  Для заданного дня недели, номера недели и аудитории выдать фамилии все преподавателей, которые ведут в этой аудитории занятия.

7.  По названию дисциплины выдать номера специальностей, для которых эта дисциплина читается.

8.  Определить все дисциплины, которые читают преподаватели с заданной ученой степенью.

9.  Выдать все группы, у которых ведут занятия преподаватели заданной кафедры.

10.  По фамилии старосты выдать фамилию заведующего кафедрой.

IDEF1X – диаграмма

Логическое проектирование

Отношение Кафедра

Схема отношения:

Кафедра (Название_каф, ФИО_зав_каф, Телефон, Выпускающая?)

Возможные ключи:

ФИО_зав_каф

Функциональные зависимости:

Название_каф→ФИО_зав_каф, Телефон, Выпускающая?

ФИО_зав_каф→Название_каф, Телефон, Выпускающая?

Отношение Сотрудник

Схема отношений:

Сотрудник (Таб_номер, Название_каф, ФИО)

Возможные ключи: нет.

Функциональные зависимости:

Таб_номер→Название_каф, ФИО

Отношение Преподаватели

Схема отношений:

Преподаватели (Таб_номер, Должность, Уч_степень, Уч_звание)

Возможные ключи: нет.

Функциональные зависимости:

Таб_номер→Должность, Уч_степень, Уч_звание

Отношение Инженеры

Схема отношений:

Инженеры (Таб_номер, Должность_инж)

Возможные ключи: нет.

Функциональные зависимости:

Таб_номер→Разряд, Должность_инж

Отношение Расписание

Схема отношений:

Расписание (Таб_номер,N_недели, День_недели, N_пары, N_группы, Аудитория, Дисциплина)

Возможные ключи:

Аудитория, N_недели, День_недели, N_пары

Функциональные зависимости:

Таб_номер, N_недели, День_недели, N_пары→N_группы, Аудитория, Дисциплина

Аудитория, N_недели, День_недели, N_пары→N_группы, Таб_номер, Дисциплина

Отношение Специальность

Схема отношений:

Специальность (N_ Специальности, Название_каф)

Возможные ключи: нет.

Функциональные зависимости:

N_Специальности→Название_каф

Отношение Группа

Схема отношений:

Группа (N_группы, N_специальности, Староста, Куратор)

Возможные ключи:

Староста

Куратор

Функциональные зависимости:

N_группы→N_специальности, Староста, Куратор

Староста→N_группы, N_специальности, Куратор

Куратор→N_группы, N_специальности, Староста

В соответствии с выбранной предметной областью, назначением, основными возможностями и информационными потребностями различных категорий пользователей информационной системы необходимо выполнить следующие этапы проектирования базы данных (ИС) и программного обеспечения (ПО) информационной системы (ИС):

Задание на курсовую работу

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

2.  Для каждой сущности определить атрибуты.

3.  С помощью пакета ERWIN построить lDEFlX-диаграмму.

4.  Разработать 6-7 запросов для проектируемой информационной системы.

5.  Построить логическую модель базы данных.

Содержание курсовой работы

Титульный лист.

Задание (на специальном бланке).

Содержание.

Введение. 3

1 Теоретическая часть. 4

1.1 Обзор систем управления базами данных. 4

1.2 СУБД Microsoft SQL Server 2000. 6

1.3 Язык SQL.. 7

1.4 CASE-технология моделирования информационных систем.. 10

2 Практическая часть. 11

2.1 Анализ требований. 11

2.2 Построение концептуальной модели базы данных. 12

2.3 Построение схемы базы данных в ErWin. 13

2.4 Построение физической и логической схемы базы данных. 20

Заключение. 39

Список использованных источников. 40

Перечень предметных областей:

1. Информационная система для компании сотовой связи. Компания предоставляет услуги сотовой телефонной связи по нескольким тарифным планам, имеющим определенные параметры. Имеется несколько отделений (представительств) компании. Компания постоянно развивается и регулярно вводит новые тарифные планы. Действие тарифных планов может отменяться, начиная с некоторой даты, если число абонентов, использующих данный тарифный план не превышает определенного порогового значения. Все клиенты тарифного плана, который предполагается отменить, предупреждаются об этом за определенное число дней с предложением о переходе на другие тарифные планы. Параметры тарифных планов могут меняться, также начиная с некоторой даты, о чем абонент предупреждается заранее и ему также предлагается переход на другие тарифные планы. Такой переход абонент может выполнить сам со своего сотового телефона. Если абонент не выполнил переход на другой тарифный план самостоятельно или через оператора, то в случае отмены тарифного плана телефон отключается, а в случае изменения параметров тарифного плана - абонент остается на том же тарифном плане, но уже с измененными параметрами. Заключение договоров на подключение к сети и расторжение договоров производится только через операторов сотовой связи. Причем расторжение договора может быть произведено только в центральном офисе компании. Если телефон не подключен к сети, то с него можно вызвать лишь экстренные службы. Для всех абонентов фиксируются входящие и исходящие звонки, их продолжительность, дата и время. Для каждого абонента ведется учет абонентской платы или денежных средств на текущем счету. При нулевом балансе телефон отключается, клиенту выдается соответствующее сообщение при каждой попытке вызова. В этом случае имеется только возможность вызова экстренных служб. Абонент может временно отключить телефон от сети. Имеется возможность ведения телефонной книги для каждого абонента, фильтрация звонков с учетом «белого» и «черного» списка телефонов. У телефона имеется индикатор уровня зарядки батарей. В случае необходимости можно перевести телефон в режим зарядки батареи. Необходимо разработать приложения для оператора сотовой связи и приложение, имитирующее сотовый телефон.

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

3. Информационная система для компьютерной фирмы. Фирма занимается сборкой и продажей компьютеров. В фирме имеются несколько сборочных цехов и несколько филиалов по приему заказов и продаже готовых изделий. Продаются как готовые модели по образцам, так и компьютеры индивидуальной сборки. Ведется учет деятельности филиалов. Компьютеры индивидуальной сборки, подготовленные на заказ, поставляются заказчику в основном прямо из сборочных цехов. Несколько типовых моделей имеются в каждом филиале по приему заказов. Необходимо автоматизировать оформления заказов на изготовление индивидуальных моделей и учет продажи готовых деталей. При этом не имеется права принимать заказ, не обеспеченный имеющимися деталями на складе (в цеху). Должен вестись учет работ, произведенных каждым цехом. За конкретные компьютеры отвечают цеха, в которых была произведена сборка и настройка компьютера. Клиентами фирмы могут быть как юридические, так и физические лица. Для постоянных клиентов предусмотрены скидки.

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

5. Информационная система для туристической фирмы. Фирма занимается организацией туристского обслуживания. Имеется несколько постоянных маршрутов, для которых комплектуются туристские группы. Заранее известны сроки каждого маршрута. Однако при наборе группы ниже некоторого количества человек деятельность фирмы становится нерентабельной. Клиенты после заказа и оплаты маршрута имеют право от него отказаться, но при этом теряют некоторую страховую сумму. С клиентами работают операторы. Менеджер ведет учет деятельности фирмы и определяет рекламную политику. Ведется учет деятельности фирмы по каждому маршруту, временному интервалу и пр. В случае необходимости фирма проводит рекламную компанию в местных и общенациональных газетах. В рекламных целях используются только некоторые газеты. Ведется учет рекламных объявлений и анализ затрат на рекламу.

6. Информационная система для образовательной организации. Фирма занимается организацией внебюджетного образования. Имеется несколько типов краткосрочных курсов, предназначенных для изучения конкретных вопросов, связанных с программным обеспечением персональных компьютеров и система второго высшего образования. Краткосрочные курсы все имеют одинаковую длительность, система второго высшего образования имеет перечень учебных дисциплин с распределением их по часам. Имеется некоторый состав ресурсов: учебных классов, лекционных аудиторий и преподавателей. Имеется некоторый состав штатных преподавателей, в случае необходимости (перегрузка штатных преподавателей, отсутствие соответствующей квалификации), привлекаются преподаватели совместители. Ведется учет преподавателей и их деятельности. Клиентами фирмы могут быть физические лица, а также организации, посылающие своих работников на переподготовку. Для групп, занимающихся на курсах, и для групп, получающих второе высшее образование, имеются соответствующие пороговые значения количества обучающихся. Нижний порог является признаком рентабельности, верхний порог определяется имеющимися ресурсами. За разработку образовательных программ, работу с преподавателями и клиентами отвечает администратор. Имеется специальный методист, составляющий расписание занятий.

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

8. Информационная система для научно-производственной фирмы. Фирма занимается разработкой программных систем. Имеется один офис, но часть разработчиков работают дома, сдавая в определенные сроки свою работу ответственному разработчику - сотруднику фирмы. В фирме имеется несколько ответственных разработчиков, каждый из которых может одновременно руководить несколькими программными проектами. Исполнитель может вести разработку сразу по нескольким проектам. Ответственный разработчик определяет задания исполнителям, несет ответственность за качество и своевременность выполнения работ по проектам. Он же проводит тестирование полученных программных продуктов и определяет исполнителям задания на внесение исправлений и доработку программ. В компании имеется группа менеджеров по продажам. Каждый менеджер отвечает за продажу, внедрение и сопровождение разработанных ранее программных продуктов. Он фиксирует замечания и претензии заказчиков, и в случае необходимости, инициирует через ответственного исполнителя модификацию программных продуктов.

9. Информационная система для гостиничного комплекса. В гостинице имеется несколько типов номеров, отличающихся количеством комнат, мебелью, максимальным количеством проживающих и пр. Имеется несколько баров, ресторанов, бассейн, спортивный зал, танц-холл, конференц-залл и другие объекты инфраструктуры. Клиентами гостиницы являются частные граждане или группы туристов. Частные граждане могут заказывать места в гостинице заранее, но не более чем за 30 дней. Они имеют возможность пользоваться услугами гостиничного комплекса (баров, ресторанов и т. д.) за отдельную плату. Группы туристов поселяются в гостинице только на основании предварительного заказа туристических фирм, с которыми у гостиницы имеются соответствующие договора. Заказ от туристических форм должен быть сделан не позднее, чем за 15 дней. Группы туристов размещаются на полном пансионе, либо на полупансионе. При оформлении предварительного заказа взимается предоплата, которая не возвращается в случае отмены заказа. Туристы имеют возможность пользоваться дополнительными услугами за отдельную плату. Посторонние лица не имеют доступ на объекты, относящиеся к гостиничному комплексу. Порте фиксирует вселение и выселение клиентов в гостинице. Главный менеджер осуществляет учет и планирование постояльцев гостиницы.

10. Информационная система для компьютерной фирмы. Фирма занимается ремонтом и «апгрейдом» персональных компьютеров. Имеется один стационарный цех и несколько приемных пунктов. В приемных пунктах, кроме приемщиков, работают дежурные мастера, которые могут выполнять срочный ремонт. Сложные заказы выполняются в фирме стационарно. Кроме того, мастера могут выезжать к заказчикам для диагностики и устранения неисправностей на месте. В распоряжении фирмы имеется два микроавтобуса, которые могут забирать аппаратуру и доставлять заказы на место. Со временем планируется увеличить количество микроавтобусов. Заказчики могут доставлять и забирать технику самостоятельно. За транспортные услуги взимается дополнительная плата. В одном из приемных пунктов приемщик дополнительно выполняет роль транспортного диспетчера. Менеджер фирмы ведет учет и анализ деятельности фирмы.

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

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

13. Информационная система для издательской фирмы. Фирма занимается издательской деятельностью. Фирма владеет типографией, выпускает книги, буклеты, периодические издания и пр. продукцию. Типографией руководит директор, отвечающий за ее работу. Клиентами типографии могут быть физические и юридические лица
. Фирма владеет и рядом периодических изданий. Каждым периодическим изданием руководит главный редактор. Главные редактора могут руководить сразу несколькими изданиями. В периодических изданиях имеются возможности размещения рекламы. В штате фирмы имеется отдел по рекламе, в составе которого работают специальные агентства, непосредственно заключающие договора на размещение рекламы.

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

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

16. Информационная система для складского учета. Разработать информационную систему, решающую задачу учета деятельности склада некоторой торговой фирмы. Фирма имеет широкий профиль деятельности. Поставщиками товаров на склад являются крупные оптовые организации. Они могут поставлять товар собственным транспортом и предоставлять скидки, зависящие от объема поставки. Может быть несколько поставщиков одного и того же товара. Потребителями товаров являются крупные и мелкие оптовики, частные предприниматели и простые граждане. Стоимость отпускаемого со склада товара зависит от многих факторов: объема партии, цены поставки и пр. Необходимо вести учет, анализ и планирование движения товаров на складе.

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

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

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

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

21. Информационная система фирмы, проводящей аукционы. Фирма занимается продажей с аукциона антикварных изделий и произведений искусства. Фирма проводит собственные аукционы, а также принимает участие в аукционах, проводимых другими организациями. Владельцы вещей, выставляемых на проводимых фирмой аукционах, юридически являются продавцами. Лица, приобретающие эти вещи, являются покупателями. Получив от продавцов партию предметов, фирма решает, на каком из аукционов выгоднее представить данный предмет. Перед проведением аукциона каждой из выставляемых на нем вещей присваивается отдельный номер лота. Две вещи, продаваемых на различных аукционах могут иметь одинаковые номера лотов. Фирма фиксирует информацию обо всех аукционах (место, дата и время проведения аукциона, специфика), продаваемых на аукционах предметах (аукцион, на которых выставляются предметы, номер лота, продавец, отправная цена, краткое словесное описание). Продавец может выставлять любое количество предметов, а покупатель – покупать любое количество предметов. Одно и то же частное лицо или фирма может