Реферат: Создание информационной модели

--PAGE_BREAK--


Табличная с определёнными связями, окончательная концептуальная модель.





ТОВАР









Уник. ключ поставщика









Уник. ключ заказчика









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









Дата изготовления









Акцизная марка









Расшиф. Штрих-кода





ЗАКАЗЧИК



Срок годности



ПОСТАВЩИК

Уник. ключ заказчика



Вес Брутто



Уник. ключ поставщика

Наименов. Заказчика



Вес Нетто



Наименов. поставщика

Юрид-ская. принад.



Цена за единицу



Юрид-ская. принад.

Ф.И.О. руководителя



Суммарная цена



Ф.И.О. руководителя

Адрес



Вид упаковки



Адрес

Телефон/факс



Уник. ключ товара



Телефон/факс

Предполагаемая цена







Номер договора

Номер накладной







Дата заключения

Пометка об оплате









Дата накладной



СЧЕТА









Уник. ключ товара









Номер счёта








Дата продажи








НДС









Сумма к оплате







Концептуальная модель переносится затем в модель данных, совместимую с выбранной СУБД. Возможно, что отраженные в концептуальной модели взаи­мосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели. Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью.

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

Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии,— подчиненными. Между главным и подчинен­ными объектами устанавливается взаимосвязь “один ко многим”. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов. Взаимосвязи между объектами напоминают взаимосвязи в генеалогическом дереве за единственным исключением: для каждого порожденного (подчиненно­го) типа объекта может быть только один исходный (главный) тип объекта.

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

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

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

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

Все актуальные требования предметной области и адекватные им “скрытые” требования на стадии проектирования должны найти свое отражение в концеп­туальной модели. Конечно, нельзя предусмотреть все возможные варианты использования и изменения базы данных. Но в большинстве предметных областей такие основные данные, как объекты и их взаимосвязи, относительно стабильны. Меняются только информационные требования, то есть способы использования данных для получения информации.

Степень независимости данных определяется тщательностью проектирования базы данных. Всесторонний анализ объектов предметной области и их взаимос­вязей минимизирует влияние изменения требований к данным в одной программе на другие программы. В этом и состоит всеобъемлющая независимость данных.

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

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

Таблица3. Проект таблицы для физической модели.

№ п/п

Наименование поля

Примечание

ТОВАР

1.

Key_tovar

Уникальный ключ товара

2.

Key_postav

Уникальный ключ поставщика

3.

Key_zakaz

Уникальный ключ заказчика

4.

Name_tovar

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

5.

Date

Дата изготовления

6.

Marka

Акцизная марка

7.

Kod

Расшифровка штрих-кода

8.

Srok_god

Срок годности

9.

Ves_b

Вес Брутто

10.

Ves_n

Вес Нетто

11.

Cena_1

Цена за единицу

12.

Cena

Суммарная цена

13.

Upakovka

Вид упаковки

ЗАКАЗЧИК

1.

Key_zakaz

Уникальный ключ заказчика

2.

Name_zakaz

Наименование заказчика

3.

Yrid_zakaz

Юридическая принадлежность

4.

FIO_zakaz

Ф.И.О. руководителя

5.

Adres_zakaz

Адрес

6.

Tel_zakaz

Телефон/факс

7.

Cena_z

Предполагаемая цена

8.

Number_N

Номер накладной

9.

Oplata

Пометка об оплате

10.

Date_N

Дата накладной

ПОСТАВЩИК

1.

Key_poctav

Уникальный ключ поставщика

2.

Name_postav

Наименование поставщика

3.

Yrid_poctav

Юридическая принадлежность

4.

FIO_postav

Ф.И.О. руководителя

5.

Adres_postav

Адрес

6.

Tel_postav

Телефон/факс

7.

Number_D

Номер договора

8.

Date_Z

Дата заключения

СЧЕТА

1.

Number_S

Номер счёта

2.

Date_P

Дата продажи

3.

Key_tovar

Уникальный ключ товара

4.

NDS

НДС

5.

Summa

Сумма к оплате

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

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

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

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

Таблица4. Таблица индексного файла «ТОВАР» для индексно-последовательного метода доступа.

Примечание (Доходя через индексы к файлу данных, посредством самого индекса считывается наименование товара и далее вся информация по полям находящаяся в записи, согласно таблицы ТОВАР).







Индексный файл

Блок 7











Значение Ключа

Номер Блока



Файл данных Блок 1







10

1



01







15

2



05

Индексный файл









10

Блок 10









Блок 2

Значение

Номер









11

Ключа

Блока









15

15

7











25

8









Блок 3

35

9



Блок 8



16

Индекс 2-го уровня



Значение

Номер



20







Ключа

Блока











20

3











25

4



Блок 4













21













25



























Блок 5







Блок 9



26







Значение

Номер



30







Ключа

Блока











30

5



Блок 6







35

6



31







Индекс 1-го уровня



35



Форма “ГЛАВНАЯ КНОПОЧНАЯ ФОРМА”

<img width=«511» height=«341» src=«ref-1_395547283-94206.coolpic» v:shapes="_x0000_i1025">    продолжение
--PAGE_BREAK--