Организация баз данных
ается внутренней моделью системы.
Внешние модели никак не связаны с типом физической памяти, в которой
будут храниться данные, и с методами доступа к этим данным. Это положение
отражает первый уровень независимости данных. С другой стороны, если
концептуальная модель способна учитывать расширение требований к системе в
будущем, то вносимые в нее изменения не должны оказывать влияния на
существующие внешние модели. Это — второй уровень независимости данных.
Построение логической модели обусловлено требованиями используемой СУБД.
Поэтому при замене СУБД она также может измениться.
С точки зрения прикладного программирования независимость данных
определяется не техникой программирования, а его дисциплиной, т.е. для того
чтобы при любом изменении системы избежать перекомпиляции приложения,
рекомендуется не определять константы (постоянные значения данных) в
программе. Лучшее решение состоит в передаче программе значений в качестве
параметров.
Все актуальные требования предметной области и адекватные им «скрытые»
требования на стадии проектирования должны найти свое отражение в
концептуальной модели. Конечно, нельзя предусмотреть все возможные варианты
использования и изменения базы данных. Но в большинстве предметных областей
такие основные данные, как объекты и их взаимосвязи, относительно
стабильны. Меняются только информационные требования, то есть способы
использования данных для получения информации.
Степень независимости данных определяется тщательностью проектирования
базы данных. Всесторонний анализ объектов предметной области и их
взаимосвязей минимизирует влияние изменения требований к данным в одной
программе на другие программы. В этом и состоит всеобъемлющая независимость
данных.
Основное различие между указанными выше тремя типами моделей данных
(концептуальной, логической и физической) состоит в способах представления
взаимосвязей между объектами. При проектировании БД требуется различать
взаимосвязи между объектами, между свойствами одного объекта и между
свойствами различных объектов.
В процессе проектирования объекты преобразуются в отношения, свойства в
поля таблиц, методы – в процедуры, формы и т.д. (что и было произведено).
Правильно проведенный объектно-ориентированный анализ позволяет значительно
облегчить работу.
Таблица 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 |
|Уни|Наи|Уни|Уни|Дат|Акц|Рас|Сро|Вес|Вес|Цен|Сум|Вид|
|кал|мен|кал|кал|а |изн|шиф|к |Бру|Нет|а |мар|упа|
|ьны|ова|ьны|ьны|изг|ая |ров|год|тто|то |за |ная|ков|
|й |ние|й |й |ото|мар|ка |нос| | |еди|цен|ки |
|клю|тов|клю|клю|вле|ка |штр|ти | | |ниц|а | |
|ч |ара|ч |ч |ния|
| |  скачать работу |
Организация баз данных |
