Наращивание экономической и статистической информации в двухструктурных реляционных базах данных (стр. 18 из 19)

2. Ведение справочника клиентов. Клиенты бывают постоянные и одноразовые, но, несмотря на это, информация о них остается в базе данных. Справочник постоянно пополняется, редактируется. Как правило, удалением информации о клиентах и пополнением справочника занимается один человек.

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

4. Распределение клиентов. С этой задачей сталкиваются в процессе формирования квитанций на выдачу муки. Идет распределение по плательщикам и неплательщикам НДС, по юридическим и физическим лицам.

5. Предоставление информации о конкретном клиенте. Все информация о поступлении зерна ведется в разрезе каждого клиента и может быть выдана по требованию самого клиента или, например, работникам налоговой инспекции.

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

10.2. Определение объектов базы данных

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

1. Клиенты(Код клиента, Название клиента, Тип клиента, Банковские реквизиты, Юридический адрес, Телефон)

Эта сущность отводится для хранения основных сведений о клиентах. Реквизит “Тип клиента” введен для указания юридического или физического лица, а также – плательщик или неплательщик он НДС. Реквизит “Код клиента” введен для однозначной идентификации клиента в рамках предприятия.

2. Культуры (Код культуры, Название культуры, Класс, Базисная влажность, Базисная зерновая примесь, Базисная сорная примесь, Базисная стекловидность, Базисная натура, Базисная клейковина)

3. Вид поступления (Код вида поступления, Название вида поступления).

Данная сущность представляет собой вид поступления зерна на предприятие. Зерно могут привозить клиенты для переработки на муку (давальческое зерно), а также предприятие может покупать зерно для собственных нужд (собственное зерно). Кроме этого, предприятие может брать участие в государственной программе по заготовке зерна (зерно госрезервов).

4. Накладные (Номер_накладной, Дата накладной, Код клиента, Номер_автомашины, Код культуры, Код вида поступления, Масса брутто, Масса тары, Масса нетто, Номер склада, Номер лабораторного анализа).

Сущность отражает поступление зерна на предприятие по накладных клиентов.

10.3. Инфологическая и даталогическая модели базы данных

Инфологическая модель базы данных изображена на рис.17.

Рис. 17. Инфологическая модель базы данных.

Звёздочками на инфологической модели показаны ключевые атрибуты.

В качестве даталогической модели базы данных была выбрана реляционная модель, поскольку именно реляционная модель является результатом более развитых представлений о формировании и ведении баз данных, на которые наложен строгий математический аппарат. Реляционные модели наиболее логично и наглядно отражают структуру хранимой информации и внутренних связей, что позволяет более полно анализировать структуру базы данных при разработке. Это привело к тому, что именно реляционные модели баз данных наиболее распространены в настоящее время и являются стандартом, на который переводятся все существовавшие ранее базы данных с иерархической и сетевой моделью. Ещё одним веским доводом в пользу выбора реляционной модели является тот факт, что подавляющее большинство предоставляемых средств для разработки баз данных ориентированны исключительно на реляционную модель. Кроме того, реляционные базы данных в последствии легче расширять и интегрировать, что является неотъемлемой частью дальнейшего развития баз данных, с увеличением возлагаемых на них задач.

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

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

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

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

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

10.4. Физическое описание модели

База данных организованна в популярном формате локальных баз данных dBase. Этот формат для организации реляционных баз данных довольно распространен, поскольку обладает очень развитой системой хранимых типов данных, возможностями индексирования полей, что позволяет получать доступ к данным за минимальное время, а также функциями по обеспечению ссылочной целостности между реляционными таблицами, что позволяет разработчику минимизировать временные затраты на создание базы данных, а конечному пользователю затраты на поддержание целостности хранимых данных и получения из базы данных самих хранимых данных. Поскольку базы данных dBase - реляционные базы данных, то запросы к данным осуществляются с помощью реляционного языка запросов SQL. Благодаря развитой системе определения ключевых полей и индексов при создании таблиц запросы будут выполняться с минимальными временными затратами. Хотя этот фактор для локальных баз данных не является ключевым, однако, при росте объема хранимых данных именно скорость выполнения запросов становиться решающим фактором при выборе формата баз данных.

Типы данных, хранимые в таблицах dBase, очень разнообразны. Это и символьные значения и разнообразные типы числовых значений, включающие целочисленные, вещественные, вещественные с плавающей запятой, числа в двоичном и двоично-десятичном формате, логические типы, специальные форматы для хранения значений даты, времени и денежных сумм, графические типы для хранения графических изображений в самых популярных форматах, а также строковые значения неограниченной длины (в том числе и форматированные в формате rtf) и даже типы поддерживаемые технологией OLE (Object Linking and Embedding) фирмы Micrоsoft. Такое разнообразие типов данных может отвечать даже самым изысканным задачам, которым призвана служить создаваемая база данных и без сомнения подходит для решения круга задач возложенного на базу данных о зерна зерноперерабатывающего предприятия.

База данных ZERNO представлена 4-мя таблицами (или по терминологии реляционных баз данных - 4-мя реляционными отношениями): Dorg, Dkul, Dtyp, Fnakl. Рассмотрим структуру каждой более подробно.

В таблице Dorgпредставлена информация о клиентах. Поля, их типы, и назначение представлены в таблице 2.

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