Организация баз данных
Рефераты >> Программирование и компьютеры >> Организация баз данных

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

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

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

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

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

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

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

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

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

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

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

Таблица 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

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


Страница: