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