Системы управления базами данных

Концептуальное проектирование: перечень сущностей и атрибутов. Инфологическое проектирование: модель "сущность-связь", классификация связей, реляционная модель БД. Функциональные зависимости между атрибутами. Создание отчетов и запросов к базе данных.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 22.01.2014
Размер файла 379,9 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Содержание

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

6 Физическое проектирование

6.1 Создание проекта

6.2 Создание базы данных

6.3 Создание таблиц

6.4 Создание запросов к базе данных

6.5 Создание отчетов

Заключение

Список используемой литературы

Приложение А

Приложение Б

Приложение В

Введение

концептуальное инфологическое проектирование база данные

Увеличивается количество знаний, получаемых человечеством, следовательно, возникает необходимость эффективной организации их хранения и управления доступом к ним. Поэтому большое значение имеют автоматизированные банки данных. Предметом нашего рассмотрения является программное обеспечение автоматизированного банка данных - системы управления базами данных.

Системы управления базами данных (СУБД) играют исключительную роль в организации современных промышленных, инструментальных и исследовательских информационных систем. Тематика СУБД поистине безгранична.

Современное производство немыслимо без управляющих систем разной степени сложности. Но любой управляющей системе необходимо соответствующее информационное и программное обеспечение, иначе она не сможет продуктивно работать. Если рассматривать информационное обеспечение (базы данных), то современный рынок программного обеспечения может предложить довольно большой выбор СУБД, ориентированных на различных пользователей: от мелких предпринимателей до крупных предприятий и корпораций. Поэтому для облегчения работы как мелких предпринимателей так и крупных предприятий актуальным является создание баз данных.

Целью данной работы является проектирование базы данных для информационной системы «Грузоперевозки». В процессе разработки были поставлены следующие задачи: проанализировать предметную область, разработать концептуальную модель базы данных, разработать логическую модель базы данных, используя средства 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НФ.

Для большинства существующих СУБД необходимо представить проект базы данных в ЗНФ, так как этого вполне достаточно практически для всех обычных приложений. При разработке исключительно больших систем, когда необходимо максимальное сокращение объемов хранимых данных, желательно произвести дальнейшую нормализацию. Но в этом случае можно столкнуться с недостатками нормализации. Поскольку порог человеческого восприятия не позволяет одновременно анализировать большое число объектов с учетом их взаимосвязей, можно утверждать, что с увеличением числа нормализованных таблиц уменьшается целостное восприятие базы данных как системы взаимосвязанных данных. Другим недостатком нормализованной базы данных является необходимость считывать связанные данные из нескольких таблиц при выполнении одного запроса.

Рисунок 2- ER-диаграмма

На следующей ER-диаграмме (рисунок 2) отображены связи и отношения между основными элементами выбранной предметной области компании X[3]

Проанализировав разработанную базу данных, можно сделать вывод, что она нормализована и соответствует третей нормальной форме, так как:

Все таблицы в базе данных соответствуют первой нормальной форме т. к. все атрибуты простые (атомарные) ;

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

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

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 знаков.

Date_pogr

Date

Дата погрузки - используется формат работы с датой в виде ДД. ММ. ГГ, что совпадает с немецким (German) форматом дат.

Date_razg

Date

Дата разгрузки - используется формат работы с датой в виде ДД. ММ. ГГ, что совпадает с немецким (German) форматом дат.

Otprav_sh

Numeric

Шифр отправителя - числовое значение от 1 до 10 знаков.

Pol_sh

Numeric

Шифр получателя - числовое значение от 1 до 10 знаков.

Status

Character

Статус грузоперевозки - принимает значения «Доставлено» или «Не доставлено»

6. Физическое проектирование

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

В данной работе проектирование происходит в среде Visual FoxPro. Visual FoxPro (VFP) - современная СУБД для персональных компьютеров, использующая реляционные базы данных, имеющая объектно-ориентированный алгоритмический язык для работы с информацией, методы визуального программирования и достаточно большие возможности. [2]

6.1 Создание проекта

Приступая к разработке нового приложения, прежде всего, создайте проект приложения. В дальнейшем вы будете добавлять в него созданные вами элементы приложения. Для создания нового проекта вы можете использовать мастер Application Wizard (Мастер приложения) или команду New (Новый) из меню File (Файл).

При выполнении команды New (Новый) на экране открывается соответствующее диалоговое окно с перечислением всех типов элементов приложения, которые возможны в Visual FoxPro, что и отображено на рисунке 3. По умолчанию установлена опция Project (Проект).

Для создания нового проекта нужно выполнить следующие действия:

Нажать кнопку New file (Новый файл).

В поле ввода Enter project (Введите имя проекта) диалогового окна Create (Создать) задать имя создаваемого проекта (proj1), убедившись, что в поле Тип файла установлен тип сохраняемого файла Project (Проект), а в поле Папка правильно выбрана папка, в расположен проект.

Рисунок 3 - Диалоговое окно New

Для сохранения созданного проекта следует нажать кнопку Сохранить. VisualFoxPro создаст файлы проекта и запишет их в указанное место. После этого откроется окно проекта Project Manager (Менеджер проекта) изображенное на рисунке 4. [4]

Рисунок 4 - Окно проекта Project Manager

6.2 Создание базы данных

Для создания базы данных нужно выполнить ряд операций:

Открыть созданный проект proj1;

Выбрать в верхней части окна конструктора проектов вкладку Data (Данные). Курсор по умолчанию устанавливается в начале вкладки назначении Databases (Базы данных) ;

Нажать кнопку New (Новый) в окне проекта;

В открывшемся диалоговом окне New Database (Новая база данных) нажать кнопку New Database (Новая база данных) ;

В поле ввода Enter database (Введите имя базы данных) появившегося на экране диалогового окна Create (Создать) задать имя создаваемой базы данных (data1), убедившись, что в поле Тип файла установлен тип сохраняемого файла Database (База данных), а в раскрывающемся списке Папка правильно указана папка, в которой будет расположен создаваемую базу данных;

Для сохранения созданной базы данных следует нажать кнопку Сохранить. После этого откроется пустое окно базы данных Database Designer (Конструктор базы данных) (рисунок 5). Используя панель инструментов Designer (Конструктор базы данных), команды меню Database (База данных) и контекстное меню, в окне конструктора базы данных можно создавать новые таблицы, модифицировать существующие, создавать для них индексы, устанавливать отношения между таблицами. [4]

Рисунок 5 - Пустое окно конструктора базы данных

6.3 Создание таблиц

Создавать таблицы следует с помощью Конструктора таблицы, потому что он предоставляет разработчику более широкие возможности при создании таблицы, чем мастер.

В конструктор таблицы можно перейти из мастера по созданию таблицы или непосредственно из диалогового окна New Table (Новая таблица), нажав кнопку New Table (Новая таблица) и введя в диалоговом окне Create (Создать) имя создаваемой таблицы. В результате выполнения этих действий откроется окно конструктора таблицы Table Designer (Конструктор таблицы).

Окно конструктора таблицы Table Designer (Конструктор таблицы) (рисунок 6) содержит три вкладки, предназначенные для определения следующих параметров:

Fields (Поля) - полей таблицы;

Indexes (Индексы) - индексов;

Table (Таблица) - условий достоверности вводимых данных, а также триггеров добавления, удаления и модификации.

Рисунок 6 - Окно конструктора таблицы Table Designer

Вкладка Fields (Поля), позволяет ввести наименование поля, тип данных, размещаемых в поле, и ширину. При определении числовых полей необходимо также задать количество десятичных знаков.

Наименования полей таблицы вводятся на вкладке Fields (Поля) в строке ввода столбца Name (Имя). При задании наименований полей вы можете использовать буквы, цифры и знак подчеркивания. Ваши попытки ввести специальные символы Visual FoxPro проигнорирует.

Длина наименования поля ограничивается 128-ю символами. Вряд ли вы воспользуетесь возможностью задавать такие длинные имена. Обычно для имен полей используют краткие названия, которые более наглядны и легко читаемы.

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

Поля таблицы предназначены для хранения в них данных. Это могут быть числа, текстовая информация, даты, графические файлы и т. д. Для определения типа данных, размещаемых в поле, используются тип поля, его ширина и количество знаков после запятой. Для их ввода предназначены столбцы Туре (Тип), Width (Ширина) и Decimal (Десятичные) вкладки Fields (Поля) конструктора таблицы. [4]

В Visual FoxPro допустимыми являются типы полей, перечисленные в таблице 11

Необходимо также создать уникальный ключ, который не будет повторятся, так называемый index.

Для создания индекса таблицы используется вкладка Indexes (Индексы) (рисунок 7) окна конструктора таблицы Table Designer (Конструктор таблицы).

Таблица 11

Типы полей Visual FoxPro

Тип

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

Отображаемые данные

Текстовый

Character

Текстовые поля могут содержать буквы, цифры и специальные символы. Максимальная ширина поля составляет 254 символа.

Числовой

Integer,

Numeric,

Float,

Double

Integer отображает целые числа от -2 147 483 647 до +2 147 483 646. Числовые поля типа Numeric и Float отображают данные с фиксированной точкой в диапазоне от -. 9999999999E+19 до. 9999999999E+20. Тип данных Double используется для хранения данных с высокой точностью в диапазоне от +4. 94065645841247E-324 до +8. 9884656743115E-307

Денежный

Currency

В поле денежного типа могут содержаться числа от -922 337 203 685 477. 5807 до922 337 203 685 477. 5807

Дата

Date

В поле типа Date может содержаться любая дата от 01. 01. 0001 до 31. 12. 9999

Дата и время

DateTime

В поле типа DateTime может содержаться любая дата от 01. 01. 0001 до 31. 12. 9999 и время от 00: 00: 00 а. m.. до 11: 59: 59 р. m.

Логический

Logical

Содержит логическое значение True (Т.) (Истина) или False (. F.) (Ложь)

Текстовое поле произвольной длины

Memo

Memo-поле содержит символьные данные большого объема

Двоичное поле произвольной длины

General

Поле данного типа предназначено для хранения в таблицах изображений и других двоичных данных

Рисунок 7 - Вкладка Indexes конструктора таблицы, предназначенная для создания индексов

Все индексы в Visual FoxPro имеют имена, задаваемые в поле Name (Имя). Слева от имени индекса в столбце Order (Упорядочение) располагается переключатель, определяющий порядок, в котором будут выстраиваться значения индексного выражения. По умолчанию при создании индекса в данном поле появляется стрелка, направленная вверх. Это означает, что значения индексного выражения упорядочены по возрастанию. Если стрелка направлена вниз, это говорит о том, что значения упорядочены по убыванию. Для изменения способа упорядочения можно нажать клавишу <Пробел>или щелкнуть кнопкой мыши.

Список Туре (Тип) используется для задания типа создаваемого индекса и содержит значения, описанные в таблице 12.

Таблица 12

Описание типов индекса

Тип индекса

Описание

Regular (Обычный)

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

Candidate (Кандидат)

Создается уникальный индекс, который не содержит полей с пустыми значениями. Этот индекс обладает всеми качествами первичного ключа и не является им только по той причине, что таблица не может содержать более одного первичного ключа

Primary (Первичный)

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

Созданные в данной работе таблицы с установленными между ними связями указаны в приложение А.

6.4 Создание запросов к базе данных

Выборка информации из базы данных может осуществляться:

- с помощью команды SELECT SQL языка Visual FoxPro, которая является аналогом соответствующей команды SQL;

- с помощью мастера запросов;

- с помощью конструктора запроса.

Команда SELECT имеет множество возможностей (опций). Ее упрощенное представление имеет вид:

SELECT Список выбираемых полей

FROM СписокТаблиц - источник данных [INTO ИмяТаблицы получателя данных]

[WHERE УсловиеВыборки]

[GROUP BY УсловиеГруппировки]

[ORDER BY УсловиеУпорядочивания вводимых данных]

Квадратные скобки указывают на необязательность опции.

Конструктор запроса позволяет:

- выбирать данные из одной или нескольких таблиц, используя сложные критерии;

- устанавливать временные связи между таблицами;

- выбирать поля и записи таблиц с требуемыми данными;

- выполнять вычисления с использованием выбранных данных.

Работа с конструктором запроса сводится к заполнению форм запроса. Результатом запроса всегда является таблица, которая может быть сохранена в массиве или созданной новой таблице, отражена на экране или оформлена в виде отчета. Данные, содержащиеся в результирующей таблице, могут быть представлены в виде графика или гистограммы. [4]

Для создания запроса в окне конструктора запросов нужно выполнить следующие действия:

На вкладке Data (Данные) конструктора проекта выбрать группу Queries (Запросы) ;

Нажать кнопку New (Новый) ;

В открывшемся диалоговом окне New Query (Новый запрос) нажать кнопку New Query (Новый запрос). Открывается диалоговое окно выбора таблиц Add Table or View (Добавить таблицу или представление данных) ;

В этом диалоговом окне выбрать таблицы, данные которых будут использоваться в запросе, и с помощью кнопки Add (Добавить) перенести их в окно конструктора запросов;

Завершив выбор таблиц, нажать кнопку Close (Закрыть).

На экране появляется окно конструктора запросов (рисунок 8), которое содержит названия выбранных таблиц, а в основном меню появляется пункт Query (Запрос). Можно приступать к формированию условий запроса. Описание вкладок приведены в таблице 13.

Рисунок 8 - Окно конструктора

Таблица 13

Назначение вкладок окна конструктора запросов

Вкладка

Назначение

Fields (Поля)

Позволяет указать поля исходных таблиц, выбираемые в результирующий запрос

Join (Объединение)

Позволяет задать условия объединения таблиц

Filter (Фильтр)

Позволяет определить фильтры, накладываемые для выбора записей

Order By (Упорядочение)

Позволяет задать критерии упорядочения данных

Group By (Группировка)

Позволяет задать условия группировки данных

Miscellaneous (Разное)

Позволяет задать дополнительные условия, такие как признак выборки повторяющихся значений, количество или процент выбора данных

Запросы, созданные в данной работе указаны, представлены в приложении Б.

6.5 Создание отчетов

Под отчетом в Visual FoxPro понимается форматированное представление данных, выводимое на экран, принтер или в файл.

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

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

Отчеты в свободной форме позволяют устранить ограничения, свойственные табличным отчетам. Для получения отчета в свободной форме можно воспользоваться стандартной формой отчета, автоматически создаваемой Visual FoxPro для каждой таблицы. В таком отчете поля исходной таблицы расположены вертикально. Конструктор отчетов позволяет разработать специальный формат отчета, в котором поля исходной таблицы будут расположены в требуемых местах отчета.

Для создания отчетов в Visual FoxPro можно использовать:

- «мастер» отчетов (Report Wizard), позволяющий быстро создать отчет, выбрав параметры сортировки и группировки данных, стиль отображения данных и их расположение;

- стандартный отчет (Quick Report), позволяющий создавать стандартный отчет, в котором поля отчета расположены определенным образом, предлагаемым программой;

- конструктор отчета, в котором можно разработать собственный отчет.

В Конструкторе отчет разбит на отдельные зоны, информация которых может присутствовать в отчете один раз (Title и Summary), в начале каждой страницы (Page Header) или в конце каждой страницы (Page Footer), в начале каждой группы (Group Header, групп может быть много) и в конце каждой группы (Group Footer), а также зона показа информации каждой записи таблицы (Detail) (рисунок 9). [4]

Рисунок 9 - Окно конструктора отчетов

Таблица 14

Описание полос отчета

Полоса

Назначение

Title (Титул)

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

Page Header

(Верхний колонтитул)

Эта полоса в отчете называется верхним колонтитулом. Данные, помещенные в полосу, печатаются в начале каждой страницы. Примерами элементов управления могут быть название отчета, текущая дата, номер страницы и т. д.

Group Header

(Группа сверху)

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

Detail (Детали)

Эта полоса содержит данные полей из таблицы или результат вычислений над ними

Group Footer (Группа снизу)

В полосе размещается итоговая информация по группе

Page Footer (Нижний колонтитул)

В нижнем колонтитуле печатается название отчета, дата, номер страницы и итоговые значения по данным текущей страницы

Summary (Итоги)

В итоговой части отчета содержится информация, появляющаяся один раз после основного отчета и содержащая итоговые значения или заключительный текст

Для дальнейшего оформления отчета необходимо присутствие на экране панели инструментов - Report Controls (рисунок 10).

Рисунок 10 - Панель инструментов Report Controls

Таблица 15

Объекты панели инструментов Report Controls

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

Назначение

Select Objects (Выбор объектов)

Является указателем выбора объектов отчета

Label (Метка)

Размещает текст

Field (Поле)

Размещает поля

Line (Линия)

Рисует линии

Rectangle (Прямоугольник)

Рисует прямоугольники

Rounded Rectangle (Скругленный прямоугольник)

Рисует прямоугольник со скругленными краями

Picture OLE Bound Control

(Изображение OLE-объект)

Помещает в отчет рисунок

Button Lock (Закрепитель кнопки)

Закрепляет выбор кнопки

Отчеты, созданные в данной работе, представлены в приложении В.

Заключение

При создании курсовой работы были приобретены практические навыки по проектированию, а именно: обследованию предметной области, проектированию базы данных, формированию запросов и отчетов.

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

В результате решения поставленной задачи были закреплены теоретические знания и приобретены практические навыки по разработке баз данных.

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

Так же были созданы запросы по выбору следующей информации:

о перевозках от данного грузоотправителя;

о перевозках к данному грузополучателю;

о незаконченных перевозках за период;

о законченных перевозках за период.

В конце были сделаны отчеты в виде ведомостей:

ведомость законченных перевозок за период;

ведомость о должниках.

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

Список используемой литературы

Краморенко Н. В. Базы данных: Учебное пособие. - Владивосток. : ТИДОТ ДВГУ, 2004. - 85 с.

Кузнецов С. Д. Основы баз данных. - 2-е изд. - М. : Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. - 484 с.

Карпова Т. С. Базы данных: модели, разработка, реализация. - СПб. : Питер, 2001. - 304 с. : ил.

Лебедев А. Н. Visual FoxPro - (Самоучитель). - М. : НТ Пресс, 2005. - 328с. : ил

Афанасьев Л. Л. и др. «Единая транспортная система и автомобильные перевозки». Учебник для студентов вузов. 2 - е изд., перераб. и доп. М. : Транспорт, 1984. 333 с.

Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших ных заведений /Под. ред. проф. А. Д. Хомоненко. - СПб. : КОРОНА принт, 2000. - 416 с.

Размещено на Allbest.ru


Подобные документы

  • Перечень используемых сущностей и атрибутов. Классификация и типы связей, их функциональные особенности. Реляционная модель базы данных, ее структура и разработка. Функциональные зависимости между атрибутами, требования к программному обеспечению.

    курсовая работа [4,0 M], добавлен 26.05.2015

  • Анализ предметной области. Предположительный набор необходимых функций. Даталогическое и инфологическое проектирование. Реляционная модель данных. Создание запросов и атрибутов. Физическая модель данных. Разработка приложения для работы с базой данных.

    курсовая работа [720,8 K], добавлен 26.04.2015

  • Обследование предметной области. Концептуальное проектирование сущностей и атрибутов. Инфологическое проектирование базы данных, ее реляционная модель. Разработка представлений для отображения результатов выборки. Экономическое обоснование результатов.

    курсовая работа [717,7 K], добавлен 23.06.2011

  • Сфера работы туристической фирмы, подлежащей автоматизации. Концептуальное проектирование базы данных. Перечень сущностей и атрибутов. Инфологическое и логическое проектирование и создание запросов. Работа с информационной системой, формирование отчетов.

    курсовая работа [6,6 M], добавлен 24.10.2013

  • Логическое проектирование базы данных по автоматизации деятельности строительной компании. Классификация связей. Реляционная модель базы данных. Функциональные зависимости между атрибутами. Выбор ключей. Нормализация отношений. Запросы к базе данных.

    курсовая работа [1,2 M], добавлен 26.05.2015

  • Выявление сущностей и связей, атрибутов сущностей и назначение первичных ключей при разработке базы данных. Реляционная модель данных. Описание стадий жизненного цикла информационной системы: анализ, проектирование, реализация, внедрение, сопровождение.

    курсовая работа [152,2 K], добавлен 11.05.2014

  • Основные типичные системы управления базами данных. Способы описания взаимодействий между объектами и атрибутами. Структурная и управляющая части иерархической модели базы данных. Представление связей, операции над данными в иерархической модели.

    реферат [30,5 K], добавлен 22.02.2011

  • Проектирование структуры базы данных предприятия с помощью СУБД Access. Установка связей между таблицами и ввод в них данных. Создание форм к базе данных, фильтрация запросов, просмотр отчетов. Получение комплексного отчета после группировки и сортировки.

    лабораторная работа [787,7 K], добавлен 22.11.2014

  • Современные системы управления базами данных (СУБД). Анализ иерархической модели данных. Реляционная модель данных. Постреляционная модель данных как расширенная реляционная модель, снимающая ограничение неделимости данных, хранящихся в записях таблиц.

    научная работа [871,7 K], добавлен 08.06.2010

  • Проектирование базы данных, содержащей информацию, которая всесторонне характеризует российский рынок медицинского оборудования. Описание атрибутов сущностей и связей, отраженных в разработанной ER-модели. Разработка отчетов, форм, запросов в базе данных.

    курсовая работа [3,2 M], добавлен 19.06.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.