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

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

6.   Если в концептуальной схеме присутствовали подтипы, то возможны два способа: все подтипы в одной таблице (а) или для каждого подтипа - отдельная таблица (б). При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется, по крайней мере, один столбец, содержащий код ТИПА; он становится частью первичного ключа. При использовании метода (б) для каждого подтипа первого уровня (для более нижних - представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы - столбцы супертипа).

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

9.5.     Физическая модель данных

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

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

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

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

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

9.6.     Этапы проектирования базы данных

Этапы проектирования базы данных с учетом рассмотренных выше аспектов:

1.   Проектирование инфологической концептуальной модели баз данных:

а) Исследование предметной области применения и выявление требований конечных пользователей и решаемых задач.

в) Анализ данных: сбор основных данных (объекты, связи между объектами).

с) Построение ER-диаграммы базы данных.

2.   Проектирование даталогической модели базы данных (учитывать требования СУБД ).

a) Потенциально возможные прикладные программы: сбор информации о потенциальных возможностях использования данных.

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

4.   Реализация базы данных (оценка при неудовлетворительных эксплуатационных характеристиках).

10.      Практическая часть 10.1.   Предметная область и задачи, возложенные на базу данных

Для демонстрации практического примера организации базы данных с помощью описанных в дипломной работе средств, спроектируем базу данных для хранения информации о качественных характеристиках и количестве зерна пшеницы. Объект - зерноперерабатывающее предприятие мукомольной промышленности. Технология приемки зерна следующая: клиенты привозят на предприятие зерно, работники производственной лаборатории берут пробы зерна с каждой машины и проводят лабораторные анализы, в результате которых определяются такие характеристики зерна – влажность, зерновая примесь, сорная примесь, проход (сито), клейковина, натура, стекловидность. Все это качественные характеристики, от которых зависит количество муки, которое заберет клиент в обмен на зерно. Наша цель – спроектировать базу данных, в которой будет храниться информация о зерне, принятом от клиентов. Подразумевается, что информация накапливается постоянно с каждым днем, она может изменяться; данная база данных является частью большого комплекса автоматизированной системы управления предприятием (АСУП).

База данных несомненно носит характер фактографической информационной системы и должна выдавать однозначные сведения на поставленные запросы. Конечными пользователями базы данных являются работники производственной лаборатории, зерноперерабатывающего цеха, бухгалтерии (отдел сбыта готовой продукции), которые относятся к категории пользователей не искушенных в вопросах ведения, администрирования баз данных и поддержании их в актуальном состоянии. Это накладывает определенные требования на разработку системы управления базой данных, при которой все методы доступа, поиска и большинство функций администрирования скрыты внутри программы и прозрачны при работе что, несомненно, скажется на разработке программного интерфейса. Более подробно все требования перечислены ниже:

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

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, которое однозначно определяет каждую запись в таблице.

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

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

В таблице Dtyp представлена информация о видах поступления зерна.. Поля, их типы, и назначение представленны в таблице 4.
В таблице Fnakl представлена информация о накладных, по которым поступает зерно. Поля, их типы, и назначение представлены в таблице 5.

Ключевые поля данной таблицы – N_Nomer и N_Date. По полю N_Nana данная таблица связана с базой данных лаборатории, где содержится информация о фактических качественных показателях принятого зерна. Структуру таблиц базы данных лаборатории я здесь приводить не буду, это отдельная задача. Кроме того, на базе данной таблицы (Fnakl) в задаче реализации готовой продукции формируются квитанции и накладные на выдачу муки клиентам.

10.5.   Програмная реализация

Все описанные таблицы, составляющие основу базы данных, функционируют в рамках созданной системы управления базой данных ”Zernot”. СУБД ”Zernot” создана средствами среды программирования Delphi 5.0.

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

Краткое описание программного проекта

Проект Azagot, реализующий доступ к БД Zerno выполнен в виде библиотеки DLL. Состоит из двух форм MainForm (главная форма) и NaklForm (форма для ввода накладных). Из библиотеки Global.DLL в проект импортируются функции работы со справочниками клиентов, культур и видов поступления соответственно ShowDovOrg, ShowDovKul, ShowDovTyp.

Доступ к таблицам БД реализован с помощью компоненты DataModule. Тексты программ приведены в дополнении к дипломной работе. Поскольку база данных о зерне тесно связана с задачами реализации муки и лабораторией, в программном интерфейсе зарезервованы визуальные компоненты для взаимосвязи с этими задачами.

Чтобы попасть в окно ввода накладных, нужно на главной форме нажать кнопку с надписью “ЗЕРНО”. После этого откроется окно, через которое непосредственно реализуется работа с базой данный “ЗЕРНО”.

Для подсчета общего количества зерна за день в программе используется компонент TQuery, с помощью свойства SQL которого процедура подсчитывания очень быстро и эффективно выводит результат.

Заключение

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

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

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

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

Список литературы

1.   Дж. Тельман, "Основы систем баз данных", Москва, Финансы и статистика', 1983г.

2.   Дейт К., "Введение в системы баз данных", Москва, 'Hаука', 1980 г.

3.   Когловский М.Р., "Технология баз данных на персональных ЭВМ", Москва, 'Финансы и статистика', 1992 г.

4.   Шумаков П. В. “Delphi 3.0 и создание баз данных”. Москва 1997г.

5.   Джон Матчо, Дэвид Р.Фолкнер. “Delphi” — пер. с англ. — М.:Бином, 1995г.

6.   A.M.Епанешников., "Программирование в среде Delphi 2.0"

7.   Дж. Мартин., "Организация баз данных в вычислительных системах" М: Мир 1978г.

8.   С.М.Диго "Проектирование и использования баз данных". Москва: Финансы и статистика 1995.

9.   Горев А., Ахаян Р., Макашарипов С. “Эффективная работа с СУБД”.СПб.:Питер, 1997.— 704 с.,ил.

10.      Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.

11.      Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.

12.      Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 2001. – 252 с.

13.      Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.

14.      Мейер М. Теория реляционных баз данных. – М.: Мир, 1998. – 608 с.

15.      Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1999. Кн. 1. – 287 с.: Кн. 2. – 320 с.

16.      Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 1985. – 344 с.

17.      Paradox for Windows: Практическое руководство. Под редакцией Оспищева Д. А. Издательство АОЗ’ "Алевар", 1993.

18.      Брябрин В.М., "Программное обеспечение персональных ЭВМ", Москва, 'Hаука', 1989 г.

19.    Шафрин Ю.А. “Основы компьютерной технологии”. М., 1998

20.    “Кибернетические диалоговые системы”, И.П.Кузнецов.

21.      “Рекоммендации по общепользовательскому интерфейсу”, Microsoft, редакция 2000г.

22. Тейксейра С., Пачеко К. Delphi 5. Руководство разоработчика.Москва-Санкт-Петербург-Киев, 2000г.