перейти к полному списку дипломных проектов

Ссылка на скачивания файла в формате .doc находится в конце странички

Этап 2 служит для выявления и определения отношений между сущностями, а также для идентификации типов отношений

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

Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются связи. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности. Значение связи характеризует её тип и выбирается из множества: "0 или 1", "0 или более", "1", "1 или более", "диапазон p:q". Пара значений связей, принадлежащая одному и тому же отношению, определит тип этого отношения.

Для большинства приложений достаточно использовать следующие типы отношений:

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

один ко многим (отношения такого типа являются наиболее часто используемыми);

многие ко многим (используется на ранних этапах проектирования с целью прояснения ситуации).

В дальнейшем каждое из отношений типа "многие ко многим" должно быть преобразовано в комбинацию типов отношений "один к одному" или "один ко многим" (возможно с введением вспомогательных ассоциативных сущностей и с введением новых отношений).

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

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

Разработка структуры базы данных включает такие основные этапы, как:

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

идентификация отношений между сущностями и указание типов отношений;

разрешение неспецифических видов отношений (многие к многим).

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

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

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

Этап 2 служит для выявления и определения отношений между сущностями, а также для идентификации типов отношений. На этом этапе допускаются неспецифические отношения "многие ко многим".

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

Этап 3 предназначен для разрешения отношений "многие ко многим".

скачать бесплатно Описание предметной области (бизнес-процессы)

Содержание дипломной работы

2 Расчет единовременных затрат на разработку ПО 4
При этом число элементов, составляющих основные подсистемы, может быть достаточно значительным, а сочетание их в различные комбинации еще более увеличивает многовариантность системы
Эффективный обмен товароносителей возможен лишь в тех случаях, когда достоверно определено их оптимальное количество и четко выполняется график их обмена с потребителями
Надежность данного решения будет меньше, так как в ходе настройки неизбежно будет внесено какое-то количество ошибок
Требования к программе или программному изделию
Из всего вышесказанного можно сделать вывод, что для работы любого предприятия необходима какая-либо информационная поддержка, которая могла бы упростить работу всех сотрудников предприятия
BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели
Прежде чем приступить к разработке системы необходимо иметь четкое описание методологии разработки, адаптированной к конкретному проекту
Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели
«Отдел продаж» Какой бы выгодный товар не получил Склад, как бы хорошо не распланировало весь процесс Генеральный директор в конечном итоге все упирается в Отдел продаж и его работников
Реализовать такую возможность в электронных таблицах практически невозможно
Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована
Этап 2 служит для выявления и определения отношений между сущностями, а также для идентификации типов отношений
Для этих целей система в общем виде условно разделяется на три составляющие: Клиенты и оформление их заказов; Поставщики, оформление заявок; БД товаров
«Оформление заказа» «Продажа» (таблица 5): №заказа: является ключевым полем данной таблицы
Прежде чем начать работу с клиентом необходимо определить статус конкретного клиента: Новый клиент или Существующий клиент

На вкладке «Документы» из перечня мы выбирает конкретный документ: Заявка, Поступление ТМЦ (купля-продажа), Поступление ТМЦ (комиссия), Поступление ТМЦ (импорт)
Итак, общая фактическая трудоемкость разработки ПО составляет:
, где
– общая трудоемкость разработки, дни; Тi – трудоемкость по стадиям, дни; n – количество стадий разработки

, Затраты на обслуживающий персонал
); Тосв – продолжительность обучения и освоения (Тосв = 42 часов)
– суточное время работы ЭВМ и принтера соответственно; Тгод – время рабочих дней в году
Вначале необходимо оценить ликвидность проекта - способность проекта отвечать по имеющимся финансовым обязательствам
Она определяется путем вычисления разности совокупного дохода за весь период функционирования проекта и всех видов расходов, суммированных за тот же период с учетом дисконтирования
Многочисленные компоненты, поддерживающие разработку приложений баз данных, обеспечивают обслуживание самых различных задач: выборку и сортировку данных