Сетевая технология планирования и учета поставок деталей для сборки автомобилей на платформе В0 в ОАО 'Автоваз'

Сетевая технология планирования и учета поставок деталей для сборки автомобилей на платформе В0 в ОАО "Автоваз"

автоматизация заказ локальный сеть

Реферат

АВТОМАТИЗАЦИЯ, CASE ТЕХНОЛОГИИ, ОФОРМЛЕНИЕ ЗАКАЗОВ, АРХИТЕКТУРА «КЛИЕНТ-СЕРВЕР», WEB-СЕРВЕР, СЕРВЕР ПРИЛОЖЕНИЙ, SQL-СЕРВЕР, ЗАПРОСЫ.

Объектом исследования является автоматизация процесса поставки деталей на ОАО «АВТОВАЗ».

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

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

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

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

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

Разработанная система предназначена для автоматизации процесса оформления заказов на ОАО «АВТОВАЗ». Использование данной системы со стороны клиентов доступно любому пользователю локальной сети.

Введение

В настоящее время активно развивается сотрудничество ОАО «Автоваз» с компанией «Renault», вследствие чего на «Автовазе» начинается сборка новых автомобилей на новых платформах. На данный момент большая часть деталей для новых моделей автомобилей поставляется из-за границы, однако некоторые детали производятся и на самом «Автовазе». Разрабатываемая система направлена на облегчение таких процессов как заказ деталей, производимых на «Автовазе», планирование графика изготовления и отгрузки деталей, учета получения готовых деталей после отгрузки.

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

Новизна курсового проекта состоит в том, что в настоящее время на «Автовазе» на платформе В0, где производят новые модели автомобилей, не реализована подобная система.

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

Областью применения данного проекта являются:

1.   ОАО «Автоваз».

2.      Дочерние предприятия ОАО «Автоваз».

Анализ поставленной задачи и постановка задачи на проектирование

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

Анализ существующей технологии обработки информации

Проанализируем технологии обработки информации, используемые в системах планирования и поставки на данный момент для автомобилей семейства «Калина». Данный анализ позволит построить модель «как есть», которая позволит выявить все недостатки в работе системы.

Процесс поставки деталей можно разделить на следующие задачи:

1.   Ведение нормативной базы;

2.      Планирование производства (формирование плана производства, программы производства);

.        Учет перемещения деталей по технологическому маршруту;

.        Учет отклонений от технологического маршрута (брак, инвентаризация и т.д.);

.        Контроль выполнения программы производства (формирование отчетов);

.        Учет состояния складов.

Схема поставки деталей представлена на рисунке 1.

Рис.

Из рисунка 1 видно, что заготовки деталей от удаленных внешних поставщиков сначала поступают на склады Дирекции по логистике, после чего направляются в цеха изготовления деталей. Заготовки же от местных внешних поставщиков и изготовляемые непосредственно на самом АВТОВАЗе, сразу поступают в цеха изготовления деталей.

Ниже представлен рисунок 2, на котором раскрывается комплекс цехов изготовления деталей:

Рисунок 2 - Комплекс цехов изготовления деталей.

Рассмотрим подробнее задачи процесса поставки деталей.

Ведение нормативной базы.

Нормативная база представляет из себя СПС (сводная производственная спецификация) - перечень маршрутов движения деталей, узловой состав и применяемость деталей в узлах.

Сопровождение СПС выполняется частично в информационной системе.

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

1.       Планирование производства.

Рисунок 3 - Планирование производства

1)       Формирование плана товарного выпуска (автомобили, запасные части, кооперация);

2)      Формирование СПС (нормативной базы);

)        Формирование программы производства (разузлованный согласно СПС план товарного выпуска по производствам, цехам, складам, контрагентам АВТОВАЗа).

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

Контроль выполнения программы производства выполняется непрерывно.

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

2.       Учет перемещения деталей по технологическому маршруту.

Схема перемещения деталей по технологическому маршруту показана на рисунке 4.

Рисунок 4 - Схема информационных потоков в информационной системе

Цифрами на рисунке 4 обозначены:

1)  Регистрация отгрузки комплектующих со складов ДпЛ. Выполняется на складах ДпЛ, печатается сопроводительный документ - “Отгрузочная ведомость”.

2)      Регистрация приемки комплектующих от внешних поставщиков. Выполняется на складах прямой поставки деталей. Печатается бирка на тарное место.

3)      Регистрация отгрузки деталей из производств МтП, ПрП. Выполняется на складах готовых деталей в МтП, ПрП, печатается сопроводительный документ - “Накладная передачи деталей”.

4)      Регистрация отгрузки готовых узлов по направлениям (в СКП, в з/ч, кооперация, МСП) Выполняется на складах готовых деталей,запасных частей, печатается сопроводительный документ - “Накладная передачи деталей”.

3.       Учет отклонений от технологического маршрута (брак).

Рисунок 5 - Учет деталей в изоляторе брака

На рисунке 5:

1)   Информирование ДпК о факте брака. В на основе ИС “Управление качеством”, формируется “Акт бракования продукции” или “Акт возврата продукции”. Чаще всего, данная операция производится вручную, или полуавтоматически.

2)   Подпись акта бракования представителями ДпК, цеха, поставщика детали (поставщика - в случае обнаружения брака по вине поставщика).

3)   Регистрация приема бракованных деталей на склад-изолятор брака. Выполняется на складе-изоляторе брака на основе документов: “Акт бракования продукции” или “Акт возврата продукции” (по данным ИС “Управления качеством”).

4)   Регистрация отгрузки брака поставщику (в случае обнаружения брака по вине поставщика). Выполняется на складе-изоляторе брака.

5)   Регистрация отгрузки брака в ООО “ПППО” (в случае обнаружения окончательного брака по вине цеха). Выполняется на складе-изоляторе брака.

В ИС ведется учет состояния склада-изолятора брака в режиме реального времени.

. Контроль выполнения программы производства (формирование отчетов)

Ответственными подразделениями в МСП, отвечающим за контроль выполнения программы производства по комплексу изготовления деталей, является ПДБ Шасси и ПО МСП.

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

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

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

Наиболее важными табуляграммами и видеограммами в ИС являются “Баланс движения деталей” (БДД) и “Контроль хода отправки” (КХО).

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

Учет состояния складов.

Типовые конфигурации автоматизированных рабочих мест (АРМ):

АРМ склада комплектующих (склады комплектующих, склады прямой поставки - входная номенклатура):

ПК (для складов прямой поставки);

принтер Zebra для печати бирки на тарное место.

АРМ склада готовых деталей (склады готовых деталей, кооперации, запасных частей, изолятор брака - выходная номенклатура):

ПК + принтер Zebra для печати бирки на тарное место;

матричный принтер для печати “Накладной передачи деталей”.

АРМ плановика ПДБ (АРМ плановика ПДБ, выполняющего функции контроля хода производства и выполнения программы производства):

ПК + лазерный принтер для печати видеограмм по контролю хода производства и выполнению программы производства.

Каждое АРМ требует только одной точки подключения в сеть (ПК). Прочее оборудование (принтеры) подключается непосредственно к ПК. АРМ на складе может быть оснащен весовым комплексом (ЭТВС), интегрированный в ИС и также не требует отдельной точки подключения. На каждом складе присутствует не менее 2 АРМ (в зависимости от объема номенклатуры). Рассмотрим основные недостатки существующей информационной системы:

1.   В случае если процесс оформления заказа или составления отчета выполняется вручную, насколько правильно он оформлен зависит от грамотности составителя. Это приводит к следующим проблемам:

·   возможны ошибки при составлении заказов из-за человеческого фактора;

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

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

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

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

Разработка новой технологии обработки информации

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

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

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

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

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

В ходе проектирования технологии необходимо построить UML диаграммы, позволяющие описать функционирование и реализацию эту систему. Ниже приведем диаграмму вариантов использования системы (use case diagram) (Рисунок 3).

Рисунок 2 - диаграмма вариантов использования проектируемой сетевой технологии.

Проектируемая сетевая технология должна обеспечивать одновременную работу до 30 человек. К ним относятся:

оператор производства Renault, который составляет заказы и принимает детали;

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

кладовщик, который отгружает детали со склада в соответствии с накладной;

рабочие, изготавливающие детали в соответствии с графиком.

Ниже приведем диаграмму последовательности (sequence diagram) для оператора Renault и АИС, поскольку именно они реализуют накопление информации о деталях в БД, которая и будет использоваться для дальнейшего статистического анализа, а также построения отчетов об изготовлении и доставке деталей.

Рисунок 3 - диаграмма последовательности работы оператора Renault

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

Выбор и разработка архитектуры сетевой технологии

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

1. Архитектура с файл - сервером.

2. Архитектура с терминал - сервером.

3. Клиент - серверная архитектура.

4. Многозвенная клиент - серверная архитектура.

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

1.   Минимальные затраты на внедрение и сопровождение.

2.      Низкие требования к аппаратуре как клиентской части так и сервера.

.        Максимально низкая нагрузка на сеть.

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

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

Сравним рассмотренные виды архитектур на соответствие предъявляемым требованиям (см. таблицу 1), и выберем подходящую.

Таблица 1 - Сравнение архитектур

Сравнив рассмотренные виды архитектур видно, что в наибольшей степени всем предъявляемым требованиям удовлетворяет архитектура клиент-сервер. Поэтому выбор будет сделан в пользу архитектуры клиент-сервер. Данная архитектура представлена на рисунке 4.

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

Рис.

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

Достоинства:

1.       Легкость построения и внедрения приложений данной архитектуры.

2.      Минимальный сетевой трафик.

.        Обеспечивает широкий спектр разграничений прав доступа к БД.

Недостатки:

1.       Сложность администрирования СУБД.

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

.        Общая производительность и надежность БД полностью зависит от конкретных технологий и особенностей применяемых в SQL сервере.

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

В данной главе будет описано все необходимое ПО, используемое для создания результирующей сетевой технологии.

Выбор сервера базы данных

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

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

Базы данных в данной системе могут быть реализованы в следующих программах: Informix, Oracle, MySQL, MS SQL Server. Для выбора наиболее подходящей программы необходимо ввести критерии выбора. Для ввода критериев выбора нужно учесть следующие факторы:

1. затраты на приобретение;

2. время освоения;

3. максимальное число пользователей одновременно обращающихся к базе;

4. платформу;

5. способ доступа;

6. требования к сложности SQL запросов;

7. скорость работы БД и СУБД;

8. сложность обслуживания БД.

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

На основе перечисленных факторов сформируем требования к СУБД, которые и будут являться критериями для выбора наиболее подходящей СУБД.

Таблица 2 - Требования к СУБД для создаваемой системы

Для выбора наиболее подходящей СУБД каждый из перечисленных параметров будет оцениваться по двухбалльной шкале: 0 и 1. Оценка «1» соответствует выполнению требования, оценка «0» означает невыполнение требования.

Таблица 3 - Сравнение SQL - серверов

На основе данного анализа, очевидно, что система MySQL является достаточной для создания нужной БД, но при этом она бесплатная. Следовательно, для реализации проекта будет взята СУБД MySQL.

Выбор языка написания серверных сценариев сетевой технологии

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

Код программ, работающих на стороне клиента (посетителя сайта) выполняется на компьютере посетителя сайта, в браузере, запущенном на компьютере пользователя (Internet Explorer, Opera, Netscape, Firefox и др.). Этот код пишется на языках JavaScript и VBScript.

Программа, используемая на стороне сервера, вставляет сгенерированные ею конструкции HTML и не передается клиенту, т.е. посетитель, просмотрев код страницы, никогда не увидит кода, генерирующего фрагменты HTML. Эти программы пишутся на таких языках программирования:

PHP;;.

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

Быстрота выполнения кода.

Этот критерий является очень важным. Оценивается по трехбалльной шкале:

- медленное выполнение кода;

- средняя скорость выполнения кода;

- быстрое выполнение кода.

Поддержка СУБД MySQL (выбрана в предыдущем пункте).

Шкала оценки:

- не поддерживает СУБД MySQL;

- поддерживает СУБД MySQL.

Выполнение приложения в любом браузере.

Шкала оценки:

- выполняется только в браузере MS Internet Explorer;

- поддерживает мало браузеров;

- выполняется в основных браузерах.

Стоимость.

- высокая стоимость среды программирования;

- средняя стоимость;

- свободное распространение.

Простота изучения (написания кода).

- сложен для понимания.

- относительно прост для изучения.

Сформируем таблицу сравнения и выберем наиболее подходящий язык программирования web-приложения.

Таблица 4 - Сравнение языков программирования web-приложений

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

Выбор web-сервера

Для организации сайтов в глобальной сети используются около двух десятков серверов. Основные из них Apache и MS IIS (Microsoft Information Server).

Web-сервер Apache работает под Windows и Unix-подобными операционными системами (Linux, FreeBSD, Solaris и т.д.). Web-сервер Apache является бесплатным продуктом с открытым исходным кодом.

Web-сервер MS IIS работает только под Windows, является коммерческим продуктом.

Таким образом, для разрабатываемой системы будет использоваться web-сервер Apache, так как он не уступает web-серверу MS IIS, но при этом является свободно распространяемым.

Итак, в данной главе определено, что технология имеет многозвенную архитектуру «клиент-сервер», состоящую из приложения, web-сервера, сервера приложений и SQL-сервера.

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

·   SQL-сервер - MySQL.

·   Web-сервер Apache.

Язык написания серверных сценариев - PHP.

Постановка задачи

В первом разделе был проведен анализ существующей информационной системы. В ходе анализа была построена модель «как есть» и выявлены основные недостатки существующей технологии обработки информации:

1.   В случае если процесс оформления заказа выполняется вручную, насколько правильно он оформлен зависит от грамотности составителя. Это приводит к следующим проблемам:

·   возможны ошибки при составлении заказов из-за человеческого фактора;

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

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

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

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

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

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

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

Архитектурой для разрабатываемой сетевой технологии стала архитектура клиент-сервер. Ключевыми лицами в работе с разрабатываемой технологией были выделены:

1.   Заказчик.

2.      Исполнитель.

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

1.   Технология создания веб-приложения PHP;

2.      SQL-сервер - MySQL;

3.      Web-сервер Apache.

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

Разработка сетевой технологии

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

Разработка логической модели данных

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

1. Системный анализ предметной области.

2. Инфологическое проектирование (концептуальная модель).

3. Даталогическое проектирование (логическая модель).

4. Физическое проектирование.

Анализ предметной области был произведён в пункте 1, остальные этапы будут рассмотрены ниже.

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

Выбор средств проектирования

Для проектирования необходимо выбрать CASE-средства. Оценка CASE-средств будет производиться по следующим критериям:

·   возможность ввода и редактирования информации, описывающей элементы данных системы и их отношения;

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

·   простота освоения. Трудовые и временные затраты на освоение средств;

·   совместимость обновлений (совместимость новых версий с существующими, включая, например, совместимость по входным или выходным данным);

·   совместимость с версиями ОС (возможность работы в среде различных версий одной и той же ОС, простота модификации CASE-средства для работы с новыми версиями ОС);

·   переносимость данных между различными версиями CASE-средства;

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

Каждый критерий может иметь оценку 0-5.

Оценка «0» означает, что данное программное обеспечение полностью не удовлетворяет требованию критерия.

Оценка «5» означает, что данный критерий выполняется полностью.

То CASE-средство, которое будет иметь наибольший балл, будет принято. Балл этого программного обеспечения не должен быть меньше 30.

Оценка отражена в таблице 7.

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

·   Vantage Team Builder (Westmount I-CASE),

·   Designer/2000;

·   Silverrun;

·   Erwin;

·   S-Designor;

·   CASE-Аналитик.

Таблица 5 - Оценка CASE-средств

Из приведённой таблицы видно, что наиболее удобным средством для проектирования является Computer Associates Erwin, так как он имеет наибольший балл.

Инфологическое проектирование

Инфологическое проектирование предполагает построение семантической модели предметной области, то есть информационной модели высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД <#"524965.files/image009.gif">

Рисунок 7 - Концептуальная модель

Таблица