Главная: Рефераты

Рефераты. Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия

4. Стоимость (ID, Код_вид_услуг, Код_веса, Стоимость)

Данная таблица (Stoimost) содержит информацию о стоимости предоставляемых услуг. Поле ID - уникальный числовой идентификатор, счетчик. Поле Код_вид услуг указывает на вид услуг, определенный в таблице "Вид услуг". Поле Код_веса указывает на единицу измерения объема выполняемых работ, определенную в таблице "Вес". Поле Стоимость хранит в себе стоимость  услуги, является вычисляемым полем.

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-средство MS Access 2003, которое позволяет проектировать реляционные модели данных. MS Access – является одновременно и 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. Проектирование физической модели базы данных

 

База данных организованна в популярном формате локальных баз данных Microsoft Access 2003. Основная цель при разработке Access 2003 состояла в упрощении построения и применения баз данных. Эта цель была достигнута благодаря предоставлению пользователям широкого круга средств, позволяющих легко отыскивать и применять большую часть возможностей продукта. К ним можно отнести: возможность речевого ввода, как для диктовки, так и для сценариев оперативного управления; благодаря новому дополнительному формату файлов Access 2003 ускоряется доступ пользователей и обработка больших баз данных; пользователь имеет возможность многократно отменять в конструкторе действия и восстанавливать результаты отмененного действия при работе с таблицами, запросами. Второй из основных целей разработки Access 2003 было упрощение доступа к важной информации и ее анализа, независимо от места расположения соответствующих данных. В приложении Access 2003 расширены возможности пользователя по доступу к информации баз данных корпоративного уровня, например Microsoft SQL Server.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29



2012 © Все права защищены
При использовании материалов активная ссылка на источник обязательна.