Физическая модель данных – модель, определяющая размещение данных на внешних носителях, методы доступа и технику индексирования. Она так же называется внутренней моделью системы.
Внешние модели (даталогические модели) никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Внутренние модели (физические модели) наоборот определяют и оперируют размещением данных и их взаимосвязях на запоминающих устройствах.
Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для поднастройки модели под конкретную БД. Существует большое разнообразие способов реализации и корректировки физических моделей современных промышленных БД, что не позволяет рассмотреть их подробно.
Физическая модель данных является полностью компьютерно-ориентированной и конечные пользователи, а порой и прикладные программисты, не имеют никакого представления о том, каким образом данные запоминаются и извлекаются или каким способом организуются индексы в таблицах для быстрого поиска или ссылочная целостность. Эти и множество других функций по методам доступа и поддержании баз данных на внешних носителях, а также способов поиска и доступа к данным в современных СУБД обеспечивается в основном ядром базы данных, что значительно облегчает задачу создания БД и их ведение.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
Этапы проектирования базы данных с учетом рассмотренных выше аспектов:
1. Проектирование инфологической концептуальной модели баз данных:
а) Исследование предметной области применения и выявление требований конечных пользователей и решаемых задач.
в) Анализ данных: сбор основных данных (объекты, связи между объектами).
с) Построение ER-диаграммы базы данных.
2. Проектирование даталогической модели базы данных (учитывать требования СУБД ).
a) Потенциально возможные прикладные программы: сбор информации о потенциальных возможностях использования данных.
3. Проектирование физической модели базы данных (оценка эксплуатационных характеристик прикладных программ).
4. Реализация базы данных (оценка при неудовлетворительных эксплуатационных характеристиках).
Для демонстрации практического примера организации базы данных с помощью описанных в дипломной работе средств, спроектируем базу данных для хранения информации о качественных характеристиках и количестве зерна пшеницы. Объект - зерноперерабатывающее предприятие мукомольной промышленности. Технология приемки зерна следующая: клиенты привозят на предприятие зерно, работники производственной лаборатории берут пробы зерна с каждой машины и проводят лабораторные анализы, в результате которых определяются такие характеристики зерна – влажность, зерновая примесь, сорная примесь, проход (сито), клейковина, натура, стекловидность. Все это качественные характеристики, от которых зависит количество муки, которое заберет клиент в обмен на зерно. Наша цель – спроектировать базу данных, в которой будет храниться информация о зерне, принятом от клиентов. Подразумевается, что информация накапливается постоянно с каждым днем, она может изменяться; данная база данных является частью большого комплекса автоматизированной системы управления предприятием (АСУП).
База данных несомненно носит характер фактографической информационной системы и должна выдавать однозначные сведения на поставленные запросы. Конечными пользователями базы данных являются работники производственной лаборатории, зерноперерабатывающего цеха, бухгалтерии (отдел сбыта готовой продукции), которые относятся к категории пользователей не искушенных в вопросах ведения, администрирования баз данных и поддержании их в актуальном состоянии. Это накладывает определенные требования на разработку системы управления базой данных, при которой все методы доступа, поиска и большинство функций администрирования скрыты внутри программы и прозрачны при работе что, несомненно, скажется на разработке программного интерфейса. Более подробно все требования перечислены ниже:
1. Предоставление общей информации о количестве принятого зерна и его качественных характеристиках. Это совокупность сведений о количестве зерна, привезенном каждым клиентом, включает в себя общую информацию такую как название фирмы клиента или фамилия (если это физическое лицо), дата приемки зерна, номер автомашины, класс пшеницы, масса брутто (с автомашиной), масса тары (автомашины), масса нетто (чисто зерно), номер склада (куда поступило зерно). Подразумевается, что информация будет изменятся и пополнятся постоянно.
2. Ведение справочника клиентов. Клиенты бывают постоянные и одноразовые, но, несмотря на это, информация о них остается в базе данных. Справочник постоянно пополняется, редактируется. Как правило, удалением информации о клиентах и пополнением справочника занимается один человек.
3. Ведение справочника сельськохозяйственных культур.По каждой культуре по каждому классу необходимо вести данные о базисных качественных характеристиках, на основе которых в дальнейшем будет определяться отклонение фактических характеристик от базисных. Как правило, удалением информации о культурах и пополнением справочника занимается тоже один человек. Нужно учитывать и тот факт, что в будущем предприятие может работать не только с пшеницей, а и с другими культурами, например, с кукурудзой.
4. Распределение клиентов. С этой задачей сталкиваются в процессе формирования квитанций на выдачу муки. Идет распределение по плательщикам и неплательщикам НДС, по юридическим и физическим лицам.
5. Предоставление информации о конкретном клиенте. Все информация о поступлении зерна ведется в разрезе каждого клиента и может быть выдана по требованию самого клиента или, например, работникам налоговой инспекции.
6. Получение статистической информации о качестве и количестве зерна. По результатам работы за период (как правило, год) формируются статистические отчеты для статистического управления о средних качественных показателях зерна.
Анализ определенных выше задач позволяет выделить сущности (объекты) проектируемой базы данных и, построить ее инфологическую модель на языке "Таблицы-связи". В результате анализа были определены следующие объекты базы данных:
1. Клиенты (Код клиента, Название клиента, Тип клиента, Банковские реквизиты, Юридический адрес, Телефон)
Эта сущность отводится для хранения основных сведений о клиентах. Реквизит “Тип клиента” введен для указания юридического или физического лица, а также – плательщик или неплательщик он НДС. Реквизит “Код клиента” введен для однозначной идентификации клиента в рамках предприятия.
2. Культуры (Код культуры, Название культуры, Класс, Базисная влажность, Базисная зерновая примесь, Базисная сорная примесь, Базисная стекловидность, Базисная натура, Базисная клейковина)
3. Вид поступления (Код вида поступления, Название вида поступления).
Данная сущность представляет собой вид поступления зерна на предприятие. Зерно могут привозить клиенты для переработки на муку (давальческое зерно), а также предприятие может покупать зерно для собственных нужд (собственное зерно). Кроме этого, предприятие может брать участие в государственной программе по заготовке зерна (зерно госрезервов).
4. Накладные (Номер_накладной, Дата накладной, Код клиента, Номер_автомашины, Код культуры, Код вида поступления, Масса брутто, Масса тары, Масса нетто, Номер склада, Номер лабораторного анализа).
Сущность отражает поступление зерна на предприятие по накладных клиентов.
Инфологическая модель базы данных изображена на рис.17.
Рис. 17. Инфологическая модель базы данных.
Звёздочками на инфологической модели показаны ключевые атрибуты.
В качестве даталогической модели базы данных была выбрана реляционная модель, поскольку именно реляционная модель является результатом более развитых представлений о формировании и ведении баз данных, на которые наложен строгий математический аппарат. Реляционные модели наиболее логично и наглядно отражают структуру хранимой информации и внутренних связей, что позволяет более полно анализировать структуру базы данных при разработке. Это привело к тому, что именно реляционные модели баз данных наиболее распространены в настоящее время и являются стандартом, на который переводятся все существовавшие ранее базы данных с иерархической и сетевой моделью. Ещё одним веским доводом в пользу выбора реляционной модели является тот факт, что подавляющее большинство предоставляемых средств для разработки баз данных ориентированны исключительно на реляционную модель. Кроме того, реляционные базы данных в последствии легче расширять и интегрировать, что является неотъемлемой частью дальнейшего развития баз данных, с увеличением возлагаемых на них задач.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
