47144 (Информационная система грузоперевозок цинкового производства АО "Казцинк"), страница 3
Описание файла
Документ из архива "Информационная система грузоперевозок цинкового производства АО "Казцинк"", который расположен в категории "". Всё это находится в предмете "информатика" из , которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "остальное", в предмете "информатика, программирование" в общих файлах.
Онлайн просмотр документа "47144"
Текст 3 страницы из документа "47144"
О
БЩАЯ (nom_vag; kod_mater; nom_ceha; ves_suh; ves_vlag; primechanie; data).
М АТЕРИАЛ В ЦЕХ (nom_ceha; kod_mater);
ПОЛЬЗОВАТЕЛИ (login; password; fio; tip).
Между различными сущностями возникают определенные связи. Целесообразно проанализировать эти связи, а также обосновать выбор сущностей и дать определение некоторым из них.
Первым шагом в определении связей между объектами является составление перечня запросов (за каждым запросом стоят определенные процессы обработки данных).
Необходимо проанализировать имеющиеся структурные связи. Структурная связь между двумя объектами задается иерархической подчиненностью одного объекта другому (если такой подчиненности нет, то структурная связь отсутствует).
Проведем анализ связей между сущностями:
Название сущностей Название связей Связи
Материал, склад Материал в цех М:M
Вагон, простои Расчет 1:1
Вагон, тепляк Поступление 1:1
Вагон, время, пользователи Регистрация М:1
Материал, склад, вагон Общая 1:1
Данная модель отражает управленческий процесс и наряду с этим показывает особенности представления данных в разработанной автоматизированной системе.
2.3 Логическое проектирование
Технология баз данных устойчиво занимает одно из ведущих мест в прикладной информатике. Информационные технологии с каждым годом все активнее проникают в различные сферы деятельности. Построение текстовых и структурированных баз данных для разнообразных и сложных сред требует разработки методов и моделей, с помощью которых удается их описывать и структурировать. Разработчики, проектирующие базы данных для сложных предметных сред, в ряде случаев испытывают определенные трудности. В то же время мы являемся свидетелями стремительно развивающегося рынка персональных компьютеров и программных продуктов для них. Появилось большое количество инструментальных средств проектирования баз данных, такие как СУБД и сопутствующие продукты (интерпретаторы, генераторы отчетов, приложений и другие).
Основной задачей этапа логического проектирование является разработка логической схемы, ориентированной на выбранную модель организации данных и соответствующую ей систему управления базами данных (СУБД) и конфигурацию ЭВМ. Отображение инфологической модели на логическую. Модели данных, поддерживаемые СУБД, делят на сетевые, иерархические, реляционные и объектно-ориентированные. Соответственно различают сетевые, иерархические, объектно-ориентированные и реляционные СУБД.
Для создания БД управления процессом технического обслуживания наилучшим вариантом будет использование реляционной модели. Это можно обосновать тем, что реляционная модель высоко оценивается по критериям:
1) Легкости использования.
Основную часть издержек, особенно в небольших базах данных, может составить время, затрачиваемое пользователем на формулировку запросов. Следовательно, необходима модель данных, которая позволяет тщательно программировать и легко формулировать запросы;
2) Эффективность реализации.
Для больших баз данных стоимость пространства памяти и машинного времени доминируют в общих издержках реализации базы данных. Следовательно, необходима модель, в которой СУБД может легко переводить спецификации концептуальной схемы и их отображение в реализацию, эффективную с точки зрения необходимого пространства и обработки запросов. Несомненно, что по этим критериям лучшей является реляционная модель. Она оперирует только одной конструкцией, которую должен понимать конечный пользователь, формулируя запросы на данные. Благодаря этому системы доступны и тем, кто не обладает навыками пользователя ПК. В основу реляционной модели данных (РМД) положено понятие теоретико-множественных отношений. Отношение удобно представлять в виде двумерной таблицы при соблюдении определенных ограничивающих условий. Таблица понятна, удобна, обозрима и привычна для человека. Набор отношений (таблиц) может быть использован для хранения данных об объектах реального мира и моделирования связей между ними. В реляционной базе данных на каждое отношение накладывается ограничение – они должны быть нормализованы.
Для уменьшения нежелательных характеристик БД к схемам отношений применяются процедуры нормализации. Выделяют пять нормализованных форм (НФ), но практически достаточно, чтобы отношения удовлетворяли условиям 1НФ,2НФ,3НФ. Все атрибуты отношений должны быть простыми (атомарными), следовательно, находятся в первой нормальной форме (1НФ). Если в отношениях не наблюдается избыточность данных, то они находятся во второй нормальной форме (2НФ).
Отсутствие транзитивных зависимостей будет указывать на наличие третьей нормальной формы (3НФ). В данной базе данных все отношения находятся в 3 НФ. Отметим, что нормализация увеличивает число отношений в базе данных, тем самым, влияя на время обработки информации. Но в то же время, благодаря корректности и устранению дублирования данных, ускоряется выполнение операций доступа к данным. При использовании реляционной СУБД, обрабатываемая информация представляется в виде файлов базы данных, которые хранят информацию в виде записей. Ниже приведены структуры файлов базы данных:
Таблица 2.2 - Отношение МАТЕРИАЛ
| Наименование поля | Тип данных | Размер поля |
| Kod_mater | Integer | |
| Nazvanie | Varchar | 30 символов |
Таблица 2.3 - Отношение СКЛАД
| Наименование поля | Тип данных | Размер поля |
| Nom_ceha | Integer | |
| Nazvanie | Varchar | 30 символов |
Таблица 2.4 - Отношение ВАГОН
| Наименование поля | Тип данных | Размер поля |
| Nom_vag | Integer | |
| Tip_vag | Varchar | 15 символов |
| Sobstv | Integer |
Таблица 2.5 - Отношение ВРЕМЯ
| Наименование поля | Тип данных | Размер поля |
| Nom_vag | Integer | |
| Data_gdc | Date | |
| Vr_gdc | Time | |
| Data_pos_ter | Date | |
| Vr_pos_ter | Time | |
| Data_pos_skl | Date | |
| Vr_pos_skl | Time | |
| Data_vih_skl_kon | Date | |
| Vr_vih_skl_kon | Time | |
| Data_vih_ter | Date | |
| Vr_vih_ter | Time |
Таблица 2.6 - Отношение ТЕПЛЯК
| Наименование поля | Тип данных | Размер поля |
| Nom_vag | Integer | |
| Data_vih_skl_tep | Date | |
| Vr_vih_skl_tep | Time | |
| Data_pos_tep | Date | |
| Vr_pos_tep | Time | |
| Data_vih_tep | Date | |
| Vr_vih_tep | Time | |
| Data_pos_skl | Date | |
| Vr_pos_skl | Time |
Таблица 2.7 - Отношение ОБЩАЯ
| Наименование поля | Тип данных | Размер поля |
| Nom_vag | Integer | |
| Kod_mat | Integer | |
| Nom_ceha | Integer | |
| Ves_suh | Varchar | 10 символов |
| Ves_vlag | Varchar | 10 символов |
| Primechanie | Varchar | 255 символов |
| Data | Date |
Таблица 2.8 - Отношение ПРОСТОИ
| Наименование поля | Тип данных | Размер поля |
| Nom_vag | Integer | |
| Pros_man | Integer | |
| Pros_skl | Integer | |
| Pros_tep | Integer | |
| Fakt_vr | Integer |
Таблица 2.9 - Отношение МАТЕРИАЛ В ЦЕХ
| Наименование поля | Тип данных | Размер поля |
| Nom_ceha | Integer | |
| Kod_mater | Integer |
Таблица 2.10 - Отношение ПОЛЬЗОВАТЕЛИ
| Наименование поля | Тип данных | Размер поля |
| Login | Varchar | 10 символов |
| Password | Varchar | 10 символов |
| Fio | Varchar | 30 символов |
| Tip | Varchar | 10 символов |
Выбор конкретной системы управления базой данных(СУБД).
Одним из основных критериев выбора СУБД является оценка того, насколько эффективно внутренняя модель данных, поддерживаемая системой, способна описать концептуальную схему.
Сетевые СУБД используют модель представления данных в виде произвольного графа. В иерархических СУБД данные представляются в виде древовидной (иерархической) структуры.
Имеются системы для работы с иерархическими и сетевыми моделями, однако большинство СУБД для персональных ЭВМ работают с реляционной моделью. Таковы системы Access, dBase, FoxBase, FoxPro, Paradox, Clipper. Перечисленные СУБД эффективны для создания небольших изолированных систем с несложной структурой данных, с относительно небольшими объемами данных (10Мб. – 1Гб.) и несложными запросами. За пределами такого рода ограничений эффективность использования указанных СУБД существенно снижается.
Профессиональные СУБД обеспечивают выполнение более сложных операций. Они позволяют разработчику расширять сервисные возможности – процедуры базы данных, которые вызываются клиентом и выполняются сервером более производительно, чем компьютеры на рабочих местах пользователей. К профессиональным СУБД относятся Oracle, SyBase, Informix, Interbase.
Для проектирования АРМ диспетчера отдела «управления подвижным составом» выбрана СУБД Interbase, которая поддерживает реляционную модель данных.
2.4 Программное обеспечение автоматизированного рабочего места
Программное обеспечение состоит из системного программного обеспечения и прикладного. Основой системного обеспечения является операционная система и системы программирования. Системные программы обеспечивают рациональную технологию обработки информации. Так называемые сервисные программы, которыми автоматизированные рабочие места комплектуется в зависимости от потребности в них, расширяют возможности операционной системы. Для обеспечения информационной связи в сетях автоматизированных рабочих мест и связи автоматизированных рабочих мест по различным каналам также применяются программные средства, которые можно отнести к системному программированию.
