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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


курсовая работа Проектирование базы данных для информационной системы "Грузоперевозки"

Информация:

Тип работы: курсовая работа. Добавлен: 17.07.2012. Сдан: 2011. Страниц: 36. Уникальность по antiplagiat.ru: < 30%

Описание (план):


 

    Содержание
 

Введение

       Увеличивается количество знаний, получаемых человечеством, следовательно, возникает необходимость эффективной организации их хранения и управления доступом к ним. Поэтому большое значение имеют автоматизированные банки данных. Предметом нашего рассмотрения является программное обеспечение автоматизированного банка данных - системы управления базами данных.
       Системы управления базами данных (СУБД) играют исключительную роль в организации  современных промышленных, инструментальных и исследовательских информационных систем. Тематика СУБД поистине безгранична.
       Современное производство немыслимо без управляющих  систем разной степени сложности. Но любой управляющей системе необходимо соответствующее информационное и программное обеспечение, иначе она не сможет продуктивно работать. Если рассматривать информационное обеспечение (базы данных), то современный рынок программного обеспечения может предложить довольно большой выбор СУБД, ориентированных на различных пользователей: от мелких предпринимателей до крупных предприятий и корпораций. Поэтому для облегчения работы как мелких предпринимателей так и крупных предприятий  актуальным является создание баз данных.
       Целью данной работы является проектирование базы данных для информационной системы "Грузоперевозки". В процессе разработки были поставлены следующие задачи: проанализировать предметную область, разработать концептуальную модель базы данных, разработать логическую модель базы данных, используя средства Visual FoxPro, реализовать физическое проектирование базы данных.
       Наш выбор FoxPro обусловлен, прежде всего, разносторонностью этой СУБД, удобством, как для разработчика приложений, так и для обычного пользователя. Наличие в ней языка программирования позволяет создавать сложные системы обработки данных, ориентированные на конкретные задачи и даже под конкретного пользователя. С другой стороны, в ней отражены и в разной мере используются многие современные технологии программирования: ActiveX, COM, SQL, ODBC, OLE, DCOM, API и  ISAPI, и многое другое. При всем этом она сохранила совместимость со старыми версиями под DOS, созданными еще фирмой Fox Software. Если еще добавить, что FoxPro реализован также в средах Macintosh и Unix, то наш выбор становится обоснованным. 
 
 
 

 

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

       В наши дни очень перспективным  и стремительно развивающимся видом  предоставления услуг являются грузовые перевозки, а также услуги грузчиков. Каждая уважающая себя фирма, занимающаяся грузоперевозками, предоставляет полный перечень услуг: это помощь в организации и осуществлении квартирных и офисных переездов, услуги грузчиков и экспедиторов, осуществление перевозки грузов на дальние расстояния, а также многое другое. Фирмы, занимающиеся грузоперевозками, как правило, обладают своим автопарком, размер которого зависит от степени развития фирмы. Фирма, или организация, обладающая своим автопарком и занимающаяся грузоперевозками, называется автотранспортным предприятием.
       Имеются автотранспортные предприятия общего пользования и ведомственные.
       Автотранспортное предприятие общего пользования находятся в ведении министерств автомобильного транспорта республик, областей. Они перевозят массовые грузы в городах и между городами для предприятий и организаций всех отраслей народного хозяйства (такие автотранспортные предприятия специализируются по роду перевозимых грузов), пассажиров (автобусами и таксомоторами) и грузы населения.
       Ведомственные автотранспортные предприятия перевозят  грузы предприятий или групп предприятий соответствующего министерства или ведомства. Они обслуживают транспортными средствами конкретные промышленные, сельскохозяйственные или строительные предприятия (главным образом внутрипромышленные и технологические перевозки грузов) и кооперируют свою работу с автотранспортными предприятиями общего пользования.
       Автотранспортные предприятия имеют диспетчерский аппарат, который в грузовых хозяйствах изучает потоки грузов, транспортной связи промышленных предприятий, заключает договоры с грузоотправителями, соблюдает договорные условия; выдаёт сменно-суточные задания шофёрам с учётом максимально возможного использования грузоподъёмности автомобилей и минимального их пробега без груза; организует контроль за работой автомобилей на линии. В отдельных случаях они осуществляют погрузочно-разгрузочные работы, экспедиционные и складские операции, связанные с перевозкой грузов. При наличии в одном городе нескольких автотранспортных предприятий общего пользования возможна организация Центральной диспетчерской службы (ЦДС), которая руководит транспортным процессом нескольких автотранспортных предприятий.
       В данном курсовом проекте рассматривается  организация грузоперевозок компанией X. Требуется разработать информационную систему (ИС) для получения информации о текущих грузоперевозках, их состояние и основных грузовых потоках.
       Компания X осуществляет заказные грузоперевозки. Компания X обладает своим автопарком. Существуют организации-отправители и организации-получатели. Отправители  N подают в компанию заявку на осуществление перевозки. Отправитель N и компания X заключают договор, в котором оговариваются груз (наименование), сроки  доставки, способ, оплата за услуги. После компания X составляет квитанцию, в которой указан груз, дата погрузки (отправки), дата доставки и транспорт. Указанный транспорт отправляется на склад отправителю N и забирает указанный товар. В указанные сроки груз должен быть доставлен получателю M. Если оговоренные сроки не соблюдены, то компания X обязана выплатить неустойку отправителю N, размер которой оговаривается в договоре. По факту доставки груза отправителю N отправляется подтверждение приема груза, а также на расчетный счет отправителя N с расчетного счета получателя M переводиться стоимость груза. Затем отправитель N со своего расчетного счета переводит стоимость услуги на счет компании M.
       Основным  предметом грузоперевозки является груз. Груз — перемещаемый (перевозимый, транспортируемый) товар. Существует несколько классификаций грузов, благодаря которым осуществляется организация процесса транспортировки. Основная классификация грузов одного класса включает:
    опасные грузы, к которым относят предметы, материалы и вещества, которые при перевозке могут создавать угрозу или нанести вред здоровью человека, а также окружающей среде;
    скоропортящиеся грузы, к которым относят товары, которые ограничены сроком годности и особыми условиями хранения (например, пищевые продукты);
    негабаритные грузы, для которых характерны нестандартные размеры, затрудняющие их транспортировку;
    тяжеловесные грузы, особенностью которых — высокие весовые параметры транспортируемого товара;
    живой груз, для транспортировки такого груза необходимы определенные условия ТС. [5]
       Каждый  груз в данной ИС характеризуется  следующими параметрами:
    Шифр груза;
    Наименование груза;
    Количество;
    Стоимость.
       Шифром  груза является его идентификационный  номер – штрих код.
       В каждой квитанции присутствует только один груз. Грузы могут иметь одинаковые наименования, но разную стоимость.
       Как правило, заказ на исполнение грузоперевозки поступает от грузоотправителя.  Грузоотправителем может быть юридическое и физическое лицо.
       Физическое  лицо – это человек, гражданин  РФ.
       Юридическое лицо - созданная и зарегистрированная в установленном законом порядке организация.
       Каждый  грузоотправитель обладает рядом основных характеристик:
    Шифр грузополучателя;
    Имя;
    Адрес;
    Расчетный счет.
       Каждый  грузоотправитель обладает своим уникальным шифром.
       Именем  для физических лиц является их фамилия, имя и отчество, а для юридических  – название организации.
       Адресом является регистрационный адрес лица.
       У организаций имя может быть одинаковым, а адрес разным – филиалы либо отдельные помещения, принадлежащие  организации (склады). В тоже время  шифр тоже будет разным.
       Груз  от грузоотправителя доставляется компанией  к грузополучателю. Грузополучателем, как и в случае с грузоотправителем, может быть юридическое и физическое лицо.
       Грузополучатели так же обладают рядом свойств:
    Шифр грузополучателя;
    Имя;
    Адрес;
    Расчетный счет.
       Каждый  грузополучатель обладает своим  уникальным шифром.
       Состояние грузоперевозки характеризует квитанция, в которой указаны какой груз, откуда и куда направлен.
       В каждой квитанции указывается следующее:
    Номер квитанции;
    Груз;
    Транспорт;
    Дата погрузки;
    Дата разгрузки;
    Статус (Доставлен, Не доставлен);
    Грузоотправитель;
    Грузополучатель.
       Каждая  квитанция фиксирует только один процесс грузоперевозки, по которому перевозят один вид груза. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

       На  рисунке 1 представлена схема организационной структуры компании X 

       
         
 

         

         
 
 

         
 

       Рисунок 1- Схема организационной структуры биржи труда 

       Функции и должностные  обязанности:
       Бухгалтерия - выполняет работу по ведению бухгалтерского учета имущества, обязательств и операций по выплате заработной платы, выплате денежных средств, выплате пособий и т.п.
       Отдел по приему заказов – осуществляет прием заказов на перевозку грузов. Здесь же заключается договор на выполнение услуги грузоперевозки в соответствие с Гражданским Кодексом РФ.
       Консультант – предоставляет консалтинговые услуги в области транспортных грузоперевозок.
       Регистратор заказов – собственно этим человеком  подготавливаются все необходимые документы для заключения сделки.
 

    2  Концептуальное проектирование

    2.1 Перечень сущностей

       Сущность - некоторый обособленный объект или  событие моделируемой системы, имеющий определенный набор свойств - атрибутов. Отдельный элемент этого множества называется "экземпляром сущности". Сущность может обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый образец сущности, и может обладать любым количеством связей с другими сущностями. [1]
       Для базы данных было разработано 4 сущности ГРУЗ, ГРУЗООТПРАВИТЕЛИ, ГРУЗОПОЛУЧАТЕЛИ, КВИТАНЦИИ.
       Общая информация о сущностях представлена в таблице: 

       Таблица 1- Сущности БД
       Название сущности        Описание
       Груз   Информация  о грузах
       Грузоотправители   Информация  об участвующих в перевозках отправителях
       Грузополучатели   Информация  об участвующих в перевозках получателях
       Квитанции   Информация  о грузоперевозках

    2.2 Перечень атрибутов

       Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности.
       Атрибуты  сущности Груз:
       - шифр_груза;
       - наименование_груза;
       - количество;
       - стоимость.
       Атрибуты  сущности Грузоотправители:
       - шифр_грузоотправителя;
       - имя_грузоотправителя;
       - адрес;
       - рассчетный_счет.
       Атрибуты  сущности Грузополучатели:
       - шифр_грузополучателя;
       - имя_грузополучателя;
       - адрес;
       - рассчетный_счет.
       Атрибуты  сущности Квитанции
       - номер_квитанции,
       Атрибуты  сущности Квитанции:
       - шифр_груза;
       - транспорт;
       - дата_погрузки;
       - дата_разгрузки;
       - шифр_оправителя;
       - шифр_получателя;
       - статус. 

       Обоснованием  выбора данных сущностей являются исходные данные к проекту, которые были разбиты на отдельные части (таблицы) по принципу соответствия.
       В физической модели каждой сущности будет  соответствовать таблица базы данных, а каждому атрибуту - поле таблицы. Имена таблиц и полей лучше задавать с использованием латинских букв и достаточно короткими для удобства использования при программировании и для совместимости с системами, не использующими кириллицу.
       Выходная информация:
    На печать:
    ведомость законченных перевозок за период;
    ведомость о должниках.
        На экран:
    информация о перевозках от данного грузоотправителя;
    информация о перевозках к данному грузополучателю;
    информация о незаконченных перевозках за период;
    информация о законченных перевозках за период.
       Выходная  информация предоставлена для составления запросов и отчетов к разработанной базе данных.
       Для определения структуры каждой таблицы  необходимо выполнить анализ функциональных зависимостей, т. е. выяснить  какие поля зависят от других полей, а затем поля с одинаковой зависимостью организовать в отдельную таблицу. Таким образом, в одну и туже таблицу не нужно включать поля, являющиеся произвольными от других полей. В результате количество необходимых таблиц определяется числом функциональных зависимостей. Формально нормализация данных обеспечена,   если набор таблиц удовлетворяет первым трем правилам, которые называются нормальными формами.
       Этот  метод является классическим методом  проектирования реляционной базы данных. Он основан на понятии зависимости  между атрибутами отношений.
 

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

 
       Инфологическая  модель применяется на втором этапе  проектирования БД, то есть после словесного описания предметной области.
       Инфологическое  проектирование, прежде всего, связано с попыткой представления семантики предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области. Ранние теоретико-графовые модели в большей степени отображали семантику предметной области. Они в явном виде определяли иерархические связи между объектами предметной области.

       3.1 Модель «сущность-связь»

       Проблема  представления семантики давно  интересовала разработчиков, и в  семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель "сущность—связь", предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена "сущность—связь", или "Entity Relationship" (ER-модель), стала фактическим стандартом при инфологическом моделировании баз данных.
       В основе ER-модели лежат следующие  базовые понятия:
       Сущность, с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности.
       Объект, которому соответствует понятие  сущности, имеет свой набор атрибутов — характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности.
       Между сущностями могут быть установлены  связи — бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности.[3]
 

        3.2 Классификация связей

       Связи делятся на три типа по множественности:
      Один-к-одному (1:1).
       При таком типе связи каждой записи одной  таблицы соответствует не более одной записи другой таблицы и наоборот. Связанные таким образом таблицы можно легко объединить в одну. Связь часто используется для разбиения очень широких таблиц на более узкие, что позволяет уменьшить время просмотра и управлять доступом к определенным частям таблицы.
      Один-ко-многим (1:М).
       Связывает одну строку какой-либо таблицы с  двумя или несколькими строками другой. Связь устанавливается между первичным ключом основной таблицы и соответственным внешним ключом связной или подчиненной таблицы. Такие связи наиболее распространены между таблицами реляционной БД.
      Многие-ко-многим (М:М).
       Связь нельзя установить между таблицами  непосредственно, она устанавливается через третью таблицу, связную с двумя основными таблицами отношением многие к одному. [3]
 

       4 Реляционная модель  БД

 
       Реляционной называется база данных, в которой  все данные, доступные пользователю, организованны в виде таблиц, а  все операции над данными сводятся к операциям над этими таблицами.
       Рассмотрим  правила преобразования ER-модели в реляционную.
       Каждой  сущности ставится в соответствие отношение  реляционной модели данных. При этом имена сущности и отношения могут  быть различными, потому что на имена сущностей могут не накладываться дополнительные синтаксические ограничения, кроме уникальности имени в рамках модели. Имена отношений могут быть ограничены требованиями конкретной СУБД, чаще всего эти имена являются идентификаторами в некотором базовом языке, они ограничены по длине и не должны содержать пробелов и некоторых специальных символов.
       Каждый  атрибут сущности становится атрибутом  соответствующего отношения. Переименование атрибутов должно происходить в соответствии с теми же правилами, что и переименование отношений в п.1.
       Первичный ключ сущности становится PRIMARY KEY соответствующего отношения.
       В каждое отношение, соответствующее  подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).
       Для отражения категоризации сущностей  при переходе к реляционной модели возможны несколько вариантов представления. Возможно создать только одно отношение для всех подтипов одного супертипа. В него включают все атрибуты всех подтипов. Однако тогда для ряда экземпляров ряд атрибутов не будет иметь смысла. И даже если они будут иметь неопределенные значения, то потребуются дополнительные правила различения одних подтипов от других. Достоинством такого представления является то, что создается всего одно отношение.
       При втором способе для каждого подтипа  и для супертипа создаются  свои отдельные отношения. Недостатком  такого способа представления является то, что создается много отношений, однако достоинств у такого способа больше, так как вы работаете только со значимыми атрибутами подтипа. Кроме того, для возможности переходов к подтипам от супертипа необходимо в супертип включить идентификатор связи.[6]

       4.1 Функциональные зависимости между атрибутами

       Функциональные  зависимости определяют не текущее состояние БД, а все возможные ее состояния, то есть они отражают те связи между атрибутами, которые присущи реальному объекту, моделируемые в БД.
       Атрибут Y некоторого отношения функционально  зависит от X (атрибуты могут быть составными), если в любой момент времени каждому значению X соответствует одно значение Y. Функциональная зависимость обозначается X >Y.
       Избыточная  функциональная зависимость - это зависимость, заключающая в себе такую информацию, которая может быть получена на основе других зависимостей, имеющихся в базе данных.
       Полная  функциональная зависимость. Неключевой атрибут функционально полно зависит от составного ключа если он функционально зависит от всего ключа в целом, но не находится в функциональной зависимости от какого-либо из входящих в него атрибутов.
       Транзитивная  функциональная зависимость. Пусть X, Y, Z - три атрибута некоторого отношения. При этом X > Y и Y > Z, но обратное соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X. Тогда Z транзитивно зависит от X.
       Многозначная зависимость. Пусть X. Y, Z - три атрибута отношения R. В отношении R существует многозначная зависимость R.X -» R.Y только в том случае, если множество значений Y. соответствующее паре значений X и Z. зависит только от X и не зависит от Z.[2] 

       Таблица 2 – Функциональные зависимости между атрибутами сущности «Груз»
           Наименование атрибута        Функциональные  зависимости
           Shifr_gr;        Name_gr;
           Kol_vo;
           stoimost;
             
     
     
           
 
       Таблица 3 – Функциональные зависимости между атрибутами сущности «Грузоотправители»
           Наименование атрибута        Функциональные  зависимости
           Shifr_otprav;        Name_otprav;
           address;
           schet_otprav;
             
     
     
           
 
 

        Таблица 4 – Функциональные зависимости между атрибутами сущности «Грузополучатели»
           Наименование атрибута        Функциональные  зависимости
           Shifr_pol;        Name_pol;
           address;
           schet_pol;
             
     
     
           
 
       Таблица 5 – Функциональные зависимости между атрибутами сущности «Квитанции»
           Наименование атрибута        Функциональные  зависимости
           Nom_kvit;        Gruz_sh;
           transport;
           data_pogr;
           data_razgr;
           otprav_sh;
           pol_sh;
           status;
             
     
     
           

       4.2 Выбор ключей

       Ключами или ключевыми являются атрибуты, значения которых определяют значения других атрибутов. Значения ключевых атрибутов не зависят от значений никаких других атрибутов. Ключ может состоять из единственного атрибута или быть составлен из нескольких атрибутов. Эти атрибуты могут быть первичными ключами, составными первичными ключами и внешними ключами.
       Первичный ключ будет обладать следующими признаками:
    Значение гарантирует уникальность для каждого из экземпляров
    Значение не имеет скрытого смысла;
    Область определения значений будет оставаться постоянной с течением времени;
    Значения существуют для каждого из экземпляров сущности.
       Внешним ключом является атрибут или группа атрибутов, составляющих первичный ключ другой сущности. Внешний ключ может быть, а может и не быть, ключевым атрибутом в связанной сущности. Внешние ключи представляют связи между сущностями.[2]
       Для сущностей данной ИС были выбраны  следующие ключевые атрибуты: 
 
 

       Таблица 6 – Ключи сущностей
       Сущность        Ключевой  атрибут
       Груз        Shifr_gr
       Грузоотправители        Shifr_otprav
       Грузополучатели        Shifr_pol
       Квитанции        Nom_kvit

       4.3 Нормализация отношений

       Для поддержания БД в устойчивом состоянии  используется ряд механизмов, которые получили обобщенное название средств поддержки целостности. Эти механизмы применяются как статически (на этапе проектирования БД), так и динамически (в процессе работы с БД).
       Нормализация  – это формализованная процедура, в процессе выполнения которой  атрибуты данных (поля) группируются в таблицы, а таблицы в БД.
       Цель:
       -  исключить дублирования данных;
       - обеспечить целостность данных, таким образом, чтобы при изменении  одних объектов. Автоматически происходило  соответственные изменения связных с ним объектов.
       Первая  нормальная форма (1НФ). Для нее требуется, чтобы таблица была плоской и не содержала повторяющихся групп. У плоской таблицы есть только две характеристики - длина (количество записей или строк) и ширина (количество полей или столбцов). Такая таблица не должна содержать ячеек, включающих несколько значений.
       Никакую из систем управления базами данных не удовлетворяет только 1НФ, так как в этом случае необходимо определить большое число полей, многие из которых остаются в основном пустыми. Избыточные данные могут послужить причиной проблем целостности и снижение эффективности при внесении изменений, поэтому подобных решений при проектировании баз данных необходимо избегать.
       Вторая  нормальная форма (2НФ). Для 2НФ требуется, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен.
       В каждой таблице БД может существовать первичный ключ - поле или набор  полей, однозначно идентифицирующий запись.
       Значение  первичного ключа в таблице БД должно быть уникальным, т.е. в таблице не должно существовать двух и более записей с одинаковым значением первичного ключа.
       Те  поля, которые зависят только от части первичного ключа, должны быть выделены в составе отдельных таблиц. 2НФ позволяет удалить большую часть повторяющихся данных, которые часто остаются после первого этапа нормализации.
       Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.
       Отношение находится в четвертой нормальной форме (4НФ), если в нем не присутствуют функциональные многозначные зависимости. Для 4НФ требуется, чтобы в одной таблице не содержались независимые элементы данных, если между ними существует отношение "многие-ко-многим".
       Если  в отношении имеется много  функциональных зависимостей, 4НФ не устраняет избыточность, то применяют пятую нормальную форму (5НФ).
       Разложение  отношений из 4НФ в 5НФ должно быть выполнено так, чтобы каждая проекция, полученная из 4НФ, содержала не менее одного возможного ключа и хотя бы один неключевой атрибут из исходного отношения. Для 5НФ требуется, чтобы можно было восстановить исходную таблицу на основе информации таблиц, на которые она была разбита. Кроме того, необходимо, чтобы таблицы соответствовали ЗНФ, а при наличии отношений "многие-ко-многим" - 4НФ.
       Для большинства существующих СУБД необходимо представить проект базы данных в  ЗНФ, так как этого вполне достаточно практически для всех обычных приложений. При разработке исключительно больших систем, когда необходимо максимальное сокращение объемов хранимых данных, желательно произвести дальнейшую нормализацию. Но в этом случае можно столкнуться с недостатками нормализации. Поскольку порог человеческого восприятия не позволяет одновременно анализировать большое число объектов с учетом их взаимосвязей, можно утверждать, что с увеличением числа нормализованных таблиц уменьшается целостное восприятие базы данных как системы взаимосвязанных данных. Другим недостатком нормализованной базы данных является необходимость считывать связанные данные из нескольких таблиц при выполнении одного запроса.
       На  следующей ER-диаграмме (рисунок 2) отображены связи и отношения между основными элементами выбранной предметной области компании X[3]
 
       Рисунок 2- ER-диаграмма 

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

       5 Даталогическое проектирование

 
       Даталогическая  модель является моделью логического  уровня и представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. Эта модель строится в терминах информационных единиц, допустимых в той конкретной СУБД, в среде которой проектируют базу данных. Этап создания даталогической модели называется даталогическим проектированием. Описание логической структуры базы данных на языке СУБД называется схемой.
       Хотя  даталогическое проектирование является логической структурой базы данных, на него влияют возможности физической организации данных, представляемые конкретной СУБД. Поэтому знание особенностей физической организации данных является полезным при проектировании логической структуры.
       Логическая  структура базы данных, а также  сама заполненная данными база данных является отображением реальной предметной области. Поэтому на выбор проектных решений самое непосредственное влияние оказывает специфика отображаемой предметной области, отраженная в инфологической модели.
       Для реляционной базы данных проектирование логической структуры заключается в том, чтобы разбить всю информацию по файлам (отношениям), а также определить состав полей (атрибутов) для каждого из этих файлов. Поля могут в себе содержать различные типы информации: целый, вещественный, символьный, дата\время, поле мемо, числовой, логический и тому подобные.  В зависимости от выбранной СУБД их названия могут отличаться.[3]

       5.1 Состав таблиц  базы данных

       В этом разделе приводится состав таблиц базы данных «Грузоперевозки». Для каждого поля таблицы указан тип и описание, в котором указываются особенности использования.  

       Таблица 7 – Состав таблицы «Груз»
Имя атрибута Формат Описание, особенности  использования
Shifr_gr Numeric Первичный ключ – уникальный шифр, идентифицирующий груз, числовое значение от 1 до 10 знаков.
Nazv_gr Character Наименование  груза – символьное значение в  диапазоне от 1 до 255 знаков
Kol_vo Numeric Количество  груза – числовое значение в диапазоне от 1 до 10 знаков.
Stoimost Currency Стоимость груза  – денежный формат значения от 0 до 8 знаков. Используемая валюта – рубль (руб).
 
 
 
 
        
       Таблица 8 – Состав таблицы «Грузоотправители»
Имя атрибута Формат Описание, особенности  использование
Shifr_otprav Numeric Первичный ключ – идентифицирующий уникальный шифр отправителя, числовое значение от 1 до 10 знаков.
Name_otprav Character Название организации  или ФИО лица – символьное значение в диапазоне от 1 до 255 знаков.
Address Character Адрес организации  или лица - символьное значение в диапазоне от 1 до 255 знаков.
Schet_otprv Numeric Расчетный счет организации или лица – числовое значение от 1 до 10 знаков.
        
 
       Таблица 9 – Состав таблицы «Грузополучатели»
Имя атрибута Формат Описание, особенности  использование
Shifr_pol Numeric Первичный ключ – идентифицирующий уникальный шифр получателя, числовое значение от 1 до 10 знаков.
Name_pol Character Название организации  или ФИО лица – символьное значение в диапазоне от 1 до 255 знаков.
Address Character Адрес организации  или лица - символьное значение в  диапазоне от 1 до 255 знаков.
Schet_pol Numeric Расчетный счет организации или лица – числовое значение от 1 до 10 знаков.
        
 
       Таблица 10 – Состав таблицы «Квитанции»
Имя атрибута Формат Описание, особенности  использование
Nom_kvit Numeric Первичный ключ – идентифицирующий уникальный номер квитанции, числовое значение от 1 до 10 знаков.
Gruz_sh Numeric Шифр груза  участвующий в перевозке - числовое значение от 1 до 10 знаков.
Transport Character Наименование  транспорта - символьное значение в  диапазоне от 1 до 255 знаков.
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.