Создание базы данных «Грузопоток» для фирмы «Спорттовары»

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

Отсюда, затраты на внедрение  составят 1000 рублей.

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

В итоге общие затраты  на создание базы данных составят:

Зобщ. = Зтруд + Зтех.сред и техн.. + Зинфр.. + Звнедр. + Зпр = 14725,92

 

Разработка ER-модели предметной области

Моделирование данных – это первый шаг на пути проектирования БД, это переход от объектов реального мира к компьютерной модели БД.

ER-модель служит для объединения различных представлений данных на концептуальном уровне.

 

 

 

 

 

 

 

 

 

 

Рис.3. ER модель

Структура записей  таблиц.

Таблица 5. Структура таблицы «Получатель»

№п/п	Идентификатор	Тип данных	Размер данных
1 2 3 4	KOD POLUCHATELYA NAIMENOVANIE POL ADRES POLUCHATELYA TELEFON	INT CHAR CHAR INT	5 50 50 50

Таблица 6. Структура таблицы «Груз»

№п/п	Идентификатор	Тип данных	Размер данных
1 2 3 4	KOD GRUZA NAIMENOVANIE GRUZA CENA	INT CHAR INT INT	5 50 16 50

Таблица 7. Структура таблицы «Договор»

№п/п	Идентификатор	Тип данных	Размер данных
1 2 3 4 5 6	NOMER PODPYNKTA KOD POLUCHATELYA KOD GRUZA KOLICHESTVO STOIMOST DATE	INT INT INT INT INT DATE	5 5 5 16 16 8

Процесс проектирования БД является итеративным, а не линейным или последовательным. Термин «итеративный» означает «повторяющийся».

Схема данных представлена на следующем рисунке:

Рис.4. Схема данных

 

Проектирование  базы данных реляционного типа.

 

 

 

 

 

 

 

 

 

 

 

 

Рис.5. База данных реляционного типа

 

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

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

Для определения  состава таблиц следует произвести нормализацию исходного иерархического отношения. Спроектированная база данных содержит три таблицы: Договор(DOG), Получатель(POL), Груз(GRUZ).Все ограничения целостности данных при подготовке программных средств для загрузки и корректировки базы данных были соблюдены. Также предусмотрена защита базы данных от несанкционированного доступа и разрушения.

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

В первой нормальной форме все атрибуты сущности атомарны, т.е. неделимы. Это условие выполнено.

Ненормализованное отношение  имеет вид:

DOG (NPP#, POL (KPOL#, NPOL, ADRES, TEL), GRUZ (KGRUZ#, NDRUZ, CENA), KOL, STOIM, DATE)

Результат нормализации:

DOG (NPP#, KPOL#, KGRUZ#, KOL, STOIM, DATE)

POL (KPOL#, NPOL, ADRES, TEL)

GRUZ (KGRUZ#, NDRUZ, CENA)

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

Шаг 0. Иерархическая структура может рассматриваться как ненормализованное отношение DOG0 и еще на двух доменах элементы, которых не является атомарным: POL0, GRUZ0.

Ненормализованное отношение имеет вид:

DOG0 (NPP#, POL0 (KPOL#, NPOL, ADRES, TEL), GRUZ0 (KGRUZ#, NDRUZ, CENA), KOL, STOIM, DATE)

Полное множество  всех нормализованных и ненормализованных  отношений имеет вид:

DOG0 (NPP#, KPOL0, KGRUZ0, KOL, STOIM, DATE)

POL0 (KPOL#, NPOL, ADRES, TEL)

GRUZ0 (KGRUZ#, NDRUZ, CENA)

Шаг 1. Приведем этот набор совокупности отношений к первой нормальной форме. Начиная с отношения, являющимся корнем иерархии, берем его первичный ключ и расширяем непосредственно подчиненный корню отношения, включая в них первичный ключ. Вычеркиваем из исходного отношения все не простые атрибуты, то есть те, у которых элементы неатомарные.

Получим совокупность отношений в первой нормальной форме:

DOG1 (NPP#, KPOL#, KGRUZ#, KOL, STOIM, DATE)

POL1 (KPOL#, NPOL, ADRES, TEL)

GRUZ1 (KGRUZ#, NDRUZ, CENA)

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

Отношение находится  в 3-й нормальной форме, т.к. оно находится  во 2-ой нормальной форме и не имеет  транзитивных зависимостей.

Дальнейшей нормализации не требуется, т.к. аномалии вставки  и аномалии удаления отсутствуют.

Запросы

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

1. SELECT Груз.[Код груза], Груз.[Наименование груза], Груз.Цена

FROM Груз

WHERE (((Груз.[Код груза])=[Введите  код груза]));

Такой запрос называется запросом с параметром. Параметром является код груза. Значение параметра вводится в диалоговом окне.

Рис.6. Запрос с параметром 1

После нажатия кнопки «OK», получаем информацию о конкретном грузе.

Рис.7. Вывод данных о грузе

Еще один пример запроса с параметром:

2. SELECT Получатель.[Код  получателя], Получатель.[Наименование  получателя], Получатель.[Адрес получателя]

FROM Получатель

WHERE (((Получатель.[Код получателя])=[Введите код получателя]));

Рис.8. Запрос с параметром 2

После ввода кода получателя выводятся сведения о данном получателе.

Рис.9. Вывод данных о получателе

Также существует простой запрос. Он необходим для выборки сведений из базы данных.

 

Проектирование  базы данных сетевого типа.

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

На связи в сетевой  модели накладываются два ограничения: они должны быть бинарными и находиться в соотношении 1:М. Если хотя бы одно из этих ограничений не выполняется, то делают соответствующие преобразования и добиваются выполнения этих ограничений. В данной базе данных эти ограничения выполняются, и преобразования не требуются.

Графическое представление предметной области в сетевой модели –

Диаграмма Бахмана - выглядит следующим образом:

 

 

 

 

 

 

 

 

 

 

 

 

Рис.10. Диаграмма Бахмана

 

P₁, P₂ – сингулярные наборы, т.е. владельцем является одна запись «система».

S₁, S₂ – физические наборы данных, которые будут содержать той или иной тип записи.

C – означает то, что записи вычисляемые, поэтому зная значение ключа KPOL или KGRUZ можно найти соответствующую запись по значению ключа.

V -    записи типа «договор» можно получить только через набор S₁ или S₂.

Описание  схемы базы данных:

 

DATABASE GRUZOPOTOK {

DATAFILE ‘GRUZOPOTOK.DAT’ CONTAINS SYSTEM, POL, GRUZ, DOG;

KEYFILE ‘GRUZOPOTOK.KEY’ CONTAINS KPOL, KGRUZ, NPP;

RECORD POL

{

KEY int  KPOL [5];

char NPOL [50];

char ADRES [50];

int TEL [50];

}

RECORD GRUZ

{

KEY int  KGRUZ [5];

char NGRUZ [50];

int CENA [16];

}

RECORD DOG

{

KEY int  NPP [5];

    int  KPOL [5];

    int  KGRUZ [5];

    int KOL [16];

    int STOIM [16];

    date DATE [8]

}

SET P1

{

ORDER  LAST;

OWNER  SYSTEM;

MEMBER POL;

}

SET P2

{

ORDER  LAST;

OWNER  SYSTEM;

MEMBER GRUZ;

}

 

SET S1

{

ORDER  LAST;

OWNER  POL;

MEMBER DOG;

}

SET S2

{

ORDER  LAST;

OWNER  GRUZ;

MEMBER DOG;

}

}

 

 

Запросы

1. Для данного получателя получить сведения о договорах:

D_OPEN();

GET(KPOL);

D_KEYFIND(KPOL);

D_SETOR(S2);

FOR(D_FINDFM(S2); DB_STATUS==S_OKAY; D_FINDNM(S2));

   { D_RECREAD(&DOG);

     <ОБРАБОТКА> }

D_CLOSE();

2. Для данного груза получить сведения о договорах:

D_OPEN();

GET(KGRUZ);

D_KEYFIND(KGRUZ);

D_SETOR(S1);

FOR(D_FINDFM(S1); DB_STATUS==S_OKAY; D_FINDNM(S1));

   { D_RECREAD(&DOG);

     <ОБРАБОТКА> }

D_CLOSE();

 

Проектирование базы данных с использованием объектно-ориентированной модели данных.

Семантическая модель данных (SDM) позволяет моделировать как данные, так и их отношения в единой структуре, называемой объектом. Поскольку основной структурой модели является объект, модель SDM получила название объектно-ориентированной модели базы данных (object oriented database model, OODM). В свою очередь OODM стала основой создания объектно-ориентированной модели БД (OODMB), управление которой осуществляется с помощью системы управления объектно-ориентированной базой данных

Каждый объект – это  сущность реального мира, взаимодействующая  с другими объектами.

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

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

Рис.11.Обмен  сообщениями между объектами

 

Классы

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

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

Рис.12. Представление класса POL

Рис.13. Пример представления класса GRUZ

Определим класс с  именем GRUZ для хранения объектов-грузов. Все объекты класса GRUZ используют одинаковую структуру (атрибуты) и отвечают на одинаковые сообщения (с помощью методов). Каждый экземпляр класса представляет собой объект с уникальным OID  и каждый объект ‘знает’, какому классу он принадлежит.

Рис.14. Иерархия классов

Свойства объектно-ориентированных моделей данных

ODM должна обладать следующими свойствами:

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

Кроме того, можно кратко сформулировать следующие основные положения:

• OOMD сущности реального мира моделируются объектами;
• каждый объект состоит из атрибутов и набора методов;
• каждый атрибут может ссылаться на другой объект или множество объектов;
• атрибуты и реализации методов скрыты (инкапсулированы) от других объектов;
• каждый объект идентифицирует уникальным идентификатором объекта (OID), независящим от значений атрибутов этого объекта;
• схожие объекты группируются в класс, который содержит описание данных (атрибуты или переменные экземпляров) и реализации методов;
• класс описывает тип объекта;
• классы организованы в иерархию классов;
• каждый объект класса наследует все свойства своего суперкласса в иерархии классов.

Пространство объектов