Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
которое позволяет проектировать реляционные модели данных. MS Access является одновременно и CASE-средством, и средой разработки , и очень мощным визуальным средством создания отчетности, ядром СУБД и средой исполнения.
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи).
Модель данных представлена в виде схемы данных на рис.4.1.
Рис.4.1. Инфологическая модель данных "сущность-связь"
Типы связей, их название, связанные сущности и атрибуты, по которым связаны сущности, представлены в таблице 4.1.
Таблица 4.1.
Тип связиНазвание связиСвязь между сущностямиАтрибутыОдин ко многимотноситсяStation, Operations_s_vagonomId, key_Station_otprОдин ко многимотноситсяStation, Operations_s_vagonomId, key_Station_naznachОдин ко многимотноситсяFront, Operations_s_vagonomId, key_Front_naznachОдин ко многимотноситсяFront, Operations_s_vagonomId, key_Front_otprОдин ко многимотноситсяVagon, Operations_s_vagonomId, key_vagonОдин ко многимотноситсяRod_vagona,
VagonId, key_rod_vagonaОдин ко многимотноситсяRaion_dvizheniya, VagonId, key_Raion_dvizhОдин ко многимотноситсяOperations_s_vagonom, Uslugi_svId, key_vagonОдин ко многимотноситсяOperation, Operations_s_vagonomId, key_operationОдин ко многимотноситсяGruz, Operations_s_vagonomId, key_GruzОдин ко многимсостоит изStoimost, Uslugi_svId, key_uslugiОдин ко многимсостоит изCeha, Uslugi_svId, key_naОдин ко многимотноситсяCeha, Uslugi_svId, key_sОдин ко многимотноситсяVid_uslug, StoimostId, key_Vid_uslugОдин ко многимотноситсяVes, StoimostId, key_ves
4.2. Проектирование логической модели базы данных
В качестве даталогической модели базы данных была выбрана реляционная модель, поскольку она обладает всеми ранее перечисленными достоинствами представления структур данных и внутренних связей.
Инфологическая модель базы данных легко отображается в реляционную даталогическую модель, используя описанные ранее правила по переводу.
В результате получается четырнадцать таблиц реляционной базы данных, где каждая сущность напрямую отражается в отдельную таблицу, атрибуты каждой сущности становятся полями этой таблицы, а первичные ключи сущности становятся первичными ключами таблицы.
На данном этапе необходимо также провести нормализацию полученных таблиц iелью устранения избыточности данных. Эта процедура в дальнейшем значительно облегчит усилия, которые будут затрачиваться на поддержании таблиц базы данных в целостном состоянии.
Если проанализировать значения полей таблицы "Вагоны", то видно, что некоторые поля, такие как, Род_вагона, Район_движения принимают некоторые значения из ограниченного набора, кроме того, эти значения представляют собой текстовые константы, которые могут быть довольно большие по длине. Аналогичными свойствами обладают поля Станция_отправления, Станция_назначения, Фронт_отправления, Фронт_назначения, Операция, Груз, Вид_услуг, Цех_отправитель, Цех_получатель, Вес других таблиц. Такие значения лучше всего хранить в отдельной таблице со своими уникальными номерами, а вместо этих длинных строк подставлять значение уникальных номеров, которые назначены каждой строке. Это позволит сократить дисковое пространство для хранения данных. Пользователь, таким образом, может выбрать некоторые значения этих полей из предложенного в списке, что несколько ускорит процесс заполнения базы данных, поскольку освобождает его от набора длинной последовательности одних и тех же строк.
Правила нормализации, описанные ранее, предписывают для таких случаев заводить отдельную таблицу для каждого поля и хранить в ней все значения характерные только для одного поля. В этом случае таблицы базы данных будут нормализованы, что не накладывает требования на процедуры поддержания базы данных в целостном состоянии, даёт возможность "безболезненных изменений" в программном коде, что может существенно сократить время разработки в дальнейшем.
4.3. Проектирование физической модели базы данных
База данных организованна в популярном формате локальных баз данных Microsoft Access 2003. Основная цель при разработке Access 2003 состояла в упрощении построения и применения баз данных. Эта цель была достигнута благодаря предоставлению пользователям широкого круга средств, позволяющих легко отыскивать и применять большую часть возможностей продукта. К ним можно отнести: возможность речевого ввода, как для диктовки, так и для iенариев оперативного управления; благодаря новому дополнительному формату файлов Access 2003 ускоряется доступ пользователей и обработка больших баз данных; пользователь имеет возможность многократно отменять в конструкторе действия и восстанавливать результаты отмененного действия при работе с таблицами, запросами. Второй из основных целей разработки Access 2003 было упрощение доступа к важной информации и ее анализа, независимо от места расположения соответствующих данных. В приложении Access 2003 расширены возможности пользователя по доступу к информации баз данных корпоративного уровня, например Microsoft SQL Server.
В Access 2003 в полной мере реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи и обеспечивает целостность данных, что предотвращает несовместимые операции обновления или удаления данных. Благодаря развитой системе определения ключевых полей и индексов при создании таблиц запросы будут выполняться с минимальными временными затратами. Кроме того, таблицы в Access 2003 снабжены средствами проверки допустимости