Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия (стр. 12 из 27)
5. Станции (ID, Станция)
Название таблицы в Access задано как Station. Данная таблица отводится для хранения списка станций. ID – уникальный идентификатор, счетчик. Поле Станция отводится под список станций.
6. Фронты (ID, Фронт)
Название таблицы в Access определено как Front. ID – уникальный идентификатор, счетчик. Поле Фронт отводится под список фронтов.
7. Род вагона (ID, Род_вагона)
Данная таблица (Rod_vagona) представляет информацию о типах вагонов. ID – уникальный идентификатор, счетчик. Поле Род_вагона отводится под список типов вагонов.
8. Район движения (ID, Район_движения)
Таблица Район движения (Raion_dvizheniya) содержит перечень районов, по которым двигаются вагоны. ID – уникальный идентификатор, счетчик. Поле Район движения отводится под список районов.
9. Операции (ID, Операция)
Таблица Операции (Operation) содержит список операций, производимых с вагоном. ID – уникальный идентификатор, счетчик. Поле Операция отводится под перечень операций.
10. Груз (ID, Груз)
Таблица Груз (Gruz) содержит список грузов, перевозимых вагонами. ID – уникальный идентификатор, счетчик. Поле Груз отводится под перечень грузов.
11. Цеха (ID, Номер_цеха, Балансовый_счет)
Таблица Цеха (Ceha) содержит список цехов, участвующих в операциях с вагонами. ID – уникальный идентификатор, счетчик. Поле Номер_цеха отводится под список цехов. Поле Балансовый_счет хранит номер балансового счета каждого цеха.
12. Вид услуг (ID, Вид_услуг)
Таблица Вид услуг (Vid_uslug) содержит список услуг, предоставляемых для работы с вагоном. ID – уникальный идентификатор, счетчик. Поле Вид_услуг отводится под перечень услуг.
13. Вес (ID, Вес)
Таблица Вес (Ves) предназначена для хранения единиц измерения для высчитывания стоимости предоставляемых услуг. ID – уникальный идентификатор, счетчик. Поле Вес отводится под перечень единиц измерения.
4.1.2 Инфологическая модель данных "сущность-связь"
Для построения инфологической модели данных использовалось CASE-средство MSAccess 2003, которое позволяет проектировать реляционные модели данных. MSAccess – является одновременно и CASE-средством, и средой разработки , и очень мощным визуальным средством создания отчетности, ядром СУБД и средой исполнения.
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи).
Модель данных представлена в виде схемы данных на рис.4.1.
Рис.4.1. Инфологическая модель данных "сущность-связь"
Типы связей, их название, связанные сущности и атрибуты, по которым связаны сущности, представлены в таблице 4.1.
Таблица 4.1.
| Тип связи | Название связи | Связь между сущностями | Атрибуты |
| Один ко многим | относится | Station, Operations_s_vagonom | Id, key_Station_otpr |
| Один ко многим | относится | Station, Operations_s_vagonom | Id, key_Station_naznach |
| Один ко многим | относится | Front, Operations_s_vagonom | Id, key_Front_naznach |
| Один ко многим | относится | Front, Operations_s_vagonom | Id, key_Front_otpr |
| Один ко многим | относится | Vagon, Operations_s_vagonom | Id, key_vagon |
| Один ко многим | относится | Rod_vagona,Vagon | Id, key_rod_vagona |
| Один ко многим | относится | Raion_dvizheniya, Vagon | Id, key_Raion_dvizh |
| Один ко многим | относится | Operations_s_vagonom, Uslugi_sv | Id, key_vagon |
| Один ко многим | относится | Operation, Operations_s_vagonom | Id, key_operation |
| Один ко многим | относится | Gruz, Operations_s_vagonom | Id, key_Gruz |
| Один ко многим | состоит из | Stoimost, Uslugi_sv | Id, key_uslugi |
| Один ко многим | состоит из | Ceha, Uslugi_sv | Id, key_na |
| Один ко многим | относится | Ceha, Uslugi_sv | Id, key_s |
| Один ко многим | относится | Vid_uslug, Stoimost | Id, key_Vid_uslug |
| Один ко многим | относится | Ves, Stoimost | Id, key_ves |
4.2 Проектирование логической модели базы данных
В качестве даталогической модели базы данных была выбрана реляционная модель, поскольку она обладает всеми ранее перечисленными достоинствами представления структур данных и внутренних связей.
Инфологическая модель базы данных легко отображается в реляционную даталогическую модель, используя описанные ранее правила по переводу.
В результате получается четырнадцать таблиц реляционной базы данных, где каждая сущность напрямую отражается в отдельную таблицу, атрибуты каждой сущности становятся полями этой таблицы, а первичные ключи сущности становятся первичными ключами таблицы.
На данном этапе необходимо также провести нормализацию полученных таблиц с целью устранения избыточности данных. Эта процедура в дальнейшем значительно облегчит усилия, которые будут затрачиваться на поддержании таблиц базы данных в целостном состоянии.
Если проанализировать значения полей таблицы "Вагоны", то видно, что некоторые поля, такие как, Род_вагона, Район_движения принимают некоторые значения из ограниченного набора, кроме того, эти значения представляют собой текстовые константы, которые могут быть довольно большие по длине. Аналогичными свойствами обладают поля Станция_отправления, Станция_назначения, Фронт_отправления, Фронт_назначения, Операция, Груз, Вид_услуг, Цех_отправитель, Цех_получатель, Вес других таблиц. Такие значения лучше всего хранить в отдельной таблице со своими уникальными номерами, а вместо этих длинных строк подставлять значение уникальных номеров, которые назначены каждой строке. Это позволит сократить дисковое пространство для хранения данных. Пользователь, таким образом, может выбрать некоторые значения этих полей из предложенного в списке, что несколько ускорит процесс заполнения базы данных, поскольку освобождает его от набора длинной последовательности одних и тех же строк.
Правила нормализации, описанные ранее, предписывают для таких случаев заводить отдельную таблицу для каждого поля и хранить в ней все значения характерные только для одного поля. В этом случае таблицы базы данных будут нормализованы, что не накладывает требования на процедуры поддержания базы данных в целостном состоянии, даёт возможность "безболезненных изменений" в программном коде, что может существенно сократить время разработки в дальнейшем.
4.3 Проектирование физической модели базы данных
База данных организованна в популярном формате локальных баз данных MicrosoftAccess 2003. Основная цель при разработке Access 2003 состояла в упрощении построения и применения баз данных. Эта цель была достигнута благодаря предоставлению пользователям широкого круга средств, позволяющих легко отыскивать и применять большую часть возможностей продукта. К ним можно отнести: возможность речевого ввода, как для диктовки, так и для сценариев оперативного управления; благодаря новому дополнительному формату файлов Access 2003 ускоряется доступ пользователей и обработка больших баз данных; пользователь имеет возможность многократно отменять в конструкторе действия и восстанавливать результаты отмененного действия при работе с таблицами, запросами. Второй из основных целей разработки Access 2003 было упрощение доступа к важной информации и ее анализа, независимо от места расположения соответствующих данных. В приложении Access 2003 расширены возможности пользователя по доступу к информации баз данных корпоративного уровня, например MicrosoftSQLServer.
В Access 2003 в полной мере реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи и обеспечивает целостность данных, что предотвращает несовместимые операции обновления или удаления данных. Благодаря развитой системе определения ключевых полей и индексов при создании таблиц запросы будут выполняться с минимальными временными затратами. Кроме того, таблицы в Access 2003 снабжены средствами проверки допустимости данных, предотвращающими некорректный ввод вне зависимости от того, как он осуществляется, а каждое поле таблицы имеет свой формат и стандартные описания, что существенно облегчает ввод данных. Access 2003 поддерживает все необходимые типы полей, в том числе, текстовый, числовой, счетчик, денежный, дата/время, MEMO, логический, гиперссылка и поля объектов OLE. Такое разнообразие типов данных может отвечать даже самым изысканным задачам, которым призвана служить создаваемая база данных. Кроме того, предусмотрена защита на уровне пользователя, что позволяет контролировать доступ к данным отдельных пользователей и целых групп.
База данных "Учет вагонов на подъездном пути на предприятии" представлена 13-ю таблицами (или по терминологии реляционных баз данных - 13-ю реляционными отношениями): Vagon, Operations_s_vagonom, Uslugi_sv, Stoimost, Station, Front, Rod_vagona, Raion_dvizheniya, Operation, Gruz, Ceha, Vid_uslug, Ves. Рассмотрим структуру каждой более подробно.
В таблице Vagonпредставлена общая информация о вагонах. Поля, их типы, и назначение представлены в таблице 4.2.
Таблица 4.2.
| Имя поля | Тип поля | Назначение |
| Id | счетчик | Код вагона |
| myMonth | текстовый | Месяц |
| myYear | текстовый | Год |
| Nomer_vagona | текстовый | Номер вагона |
| Invent_nomer | числовой | Инвентарный номер вагона |
| Year_izgot | текстовый | Год изготовления вагона |
| Gruzopodemnost | числовой | Грузоподъемность |
| Key_Rod_Vagona | числовой | Код Рода вагона |
| Iznos | текстовый | Износ |
| Key_Raion_dvizh | числовой | Код Района движения |
Первичным ключом таблицы является поле Id, которое однозначно определяет каждую запись в таблице. Поле Id поддерживает ссылочную целостность с таблицей Operations_s_vagonomс помощью поля key_vagon.