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

TTabbedNotebook - многостраничный диалог со встроенными закладками, в данном случае - закладки сверху.

TMaskEdit - аналог TEdit, но с возможностью форматированного ввода. Формат определяется в свойстве EditMask. В редакторе свойств для EditMask есть заготовки некоторых форматов: даты, валюты и т.п.

TOutline - используется для представления иерархических отношений связанных данных. Например - дерево директорий.

TStringGrid - служит для представления текстовых данных в виде таблицы. Доступ к каждому элементу таблицы происходит через свойство Cell.

TDrawGrid - служит для представления данных любого типа в виде таблицы. Доступ к каждому элементу таблицы происходит через свойство CellRect.

TImage - отображает графическое изображение на форме. Воспринимает форматы BMP, ICO, WMF. Если картинку подключить во время дизайна программы, то она прикомпилируется к EXE файлу.

TShape - служит для отображения простейших графических объектов на форме: окружность, квадрат и т.п.

TBevel - элемент для рельефного оформления интерфейса.

THeader - элемент оформления для создания заголовков с изменяемыми размерами для таблиц.

TScrollBox - позволяет создать на форме прокручиваемую область с размерами большими, нежели экран. На этой области можно разместить свои объекты.

TTimer - таймер, событие OnTimer периодически вызывается через промежуток времени, указанный в свойстве Interval. Период времени может составлять от 1 до 65535 мс.

TPaintBox - место для рисования. В обработчики событий, связанных с мышкой передаются относительные координаты мышки в TPaintBox, а не абсолютные в форме.

TFileListBox - специализированный ListBox, в котором отображаются файлы из указанной директории (св-во Directory). На названия файлов можно наложить маску, для этого служит св-во Mask. Кроме того, в св-ве FileEdit можно указать объект TEdit для редактирования маски.

TDirectoryListBox - специализированный ListBox, в котором отображается структура директорий текущего диска. В св-ве FileList можно указать TFileListBox, который будет автоматически отслеживать переход в другую директорию.

TDriveComboBox - специализированный ComboBox для выбора текущего диска. Имеет свойство DirList, в котором можно указать TDirectoryListBox, который будет отслеживать переход на другой диск.

TFilterComboBox - специализированный ComboBox для выбора маски имени файлов. Список масок определяется в свойстве Filter. В свойстве FileList указывается TFileListBox, на который устанавливается маска.

С помощью последних четырех компонент (TFileListBox, TDirectoryListBox, TDriveComboBox, TFilterComboBox) можно построить свой собственный диалог выбора файла, причем для этого не потребуется написать ни одной строчки кода.

TMediaPlayer - служит для управления мултимедйными устройствами (типа CD-ROM, MIDI и т.п.). Выполнен в виде панели управления с кнопками Play, Stop, Record и др. Для воспроизведения может понадобиться как соответствующее оборудование, так и программное обеспечение. Подключение устройств и установка ПО производится в среде Windows. Например, для воспроизведения видео, записанного в формате AVI, в потребуется установить ПО MicroSoft Video (в Windows 3.0, 3.1, WFW 3.11).

TOLEContainer - контейнер, содержащий OLE объекты. Поддерживается OLE 2.02

TDDEClientConv,TDDEClientItem, TDDEServerConv, TDDEServerItem - 4 объекта для организации DDE. С помощью этих объектов можно построить приложение как DDE-сервер, так и DDE-клиент.

TChartFX - деловая графика. Компонент позволяет строить всевозможные графики и гистограммы.

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

Информация о формах хранится в двух типах файлов - .dfm и .pas, причем первый тип файла - двоичный - хранит образ формы и ее свойства, второй тип описывает функционирование обработчиков событий и поведение компонент. Оба файла автоматически синхронизируются Delphi, так что если добавить новую форму проект, связанный с ним файл .pas автоматически будет создан, и его имя будет добавлено в проект.

Такая синхронизация и делает Delphi two-way-инструментом, обеспечивая полное соответствие между кодом и визуальным представлением. Как только добавляется новый объект или код, Delphi устанавливает т.н. “кодовую синхронизацию” между визуальными элементами и соответствующими им кодовыми представлениями.

Two-way tools - однозначное соответствие между визуальным проектированием и классическим написанием текста программы Это означает, что разработчик всегда может видеть код, соответствующий тому, что он построил при помощи визуальных инструментов и наоборот.

Визуальный построитель интерфейсов (Visual User-interface builder) дает возможность быстро создавать клиент-серверные приложения визуально, просто выбирая компоненты из соответствующей палитры. В процессе построения приложения разработчик выбирает из палитры компонент готовые компоненты как художник, делающий крупные мазки кистью. Еще до компиляции он видит результаты своей работы - после подключения к источнику данных их можно видеть отображенными на форме, можно перемещаться по данным, представлять их в том или ином виде.[4, 22].

Мощность и гибкость Delphi при работе с базами данных основана на низкоуровневом ядре - процессоре баз данных Borland Database Engine (BDE). Его интерфейс с прикладными программами называется Integrated Database Application Programming Interface (IDAPI). В принципе, сейчас не различают эти два названия (BDE и IDAPI) и считают их синонимами. BDE позволяет осуществлять доступ к данным как с использованием традиционного record-ориентированного (навигационного) подхода, так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных. Кроме BDE, Delphi позволяет осуществлять доступ к базам данных, используя технологию (и, соответственно, драйверы) Open DataBase Connectivity (ODBC) фирмы Microsoft. Но, как показывает практика, производительность систем с использованием BDE гораздо выше, чем оных при использовании ODBC. ODBC драйвера работают через специальный “ODBC socket”, который позволяет встраивать их в BDE.

Все инструментальные средства баз данных Borland - Paradox, dBase, Database Desktop - используют BDE. Все особенности, имеющиеся в Paradox или dBase, “наследуются” BDE, и поэтому этими же особенностями обладает и Delphi.

Библиотека объектов содержит набор визуальных компонент, значительно упрощающих разработку приложений для СУБД с архитектурой клиент-сервер. Объекты инкапсулируют в себя нижний уровень - Borland Database Engine.

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

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

Таблицы сохраняются в базе данных. Некоторые СУБД сохраняют базу данных в виде нескольких отдельных файлов, представляющих собой таблицы (в основном, все локальные СУБД), в то время как другие состоят из одного файла, который содержит в себе все таблицы и индексы (InterBase). Например, таблицы dBase и Paradox всегда сохраняются в отдельных файлах на диске. Директорий, содержащий dBase .DBF файлы или Paradox .DB файлы, рассматривается как база данных. Другими словами, любой директорий, содержащий файлы в формате Paradox или dBase, рассматривается Delphi как единая база данных. Для переключения на другую базу данных нужно просто переключиться на другой директорий. InterBase сохраняет все таблицы в одном файле, имеющем расширение .GDB, поэтому этот файл и есть база данных InterBase.

Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в офлайновом режиме. Разработчик в среде Delphi, проектирующий информационную систему для локальной машины (к примеру, небольшую систему учета медицинских карточек для одного компьютера), может использовать для хранения информации файлы формата .dbf (как в dBase или Clipper) или .db (Paradox). Если же он будет использовать локальный InterBase for Windows 4.0 (это локальный SQL-сервер, входящий в поставку), то его приложение безо всяких изменений будет работать и в составе большой системы с архитектурой клиент-сервер.

Масштабируемость на практике - одно и то же приложение можно использовать как для локального, так и для более серьезного клиент-серверного вариантов.[4, 22].

В состав пакета Delphi также входит множество утилит для работы и управления базами данных. Вот некоторые из них.

Database Desktop - это утилита, во многом похожая на Paradox, которая поставляется вместе с Delphi для интерактивной работы с таблицами различных форматов локальных баз данных - Paradox и dBase, а также SQL-серверных баз данных InterBase, Oracle, Informix, Sybase (с использованием SQL Links). Она позволяет создавать как структуру реляционных таблиц, так и всевозможные ограничения целостности таблиц, индексы, первичные ключи и внешние ключи.

WISQL (Windows Interactive SQL) - интерактивное средство посылки SQL-запросов к InterBase (в том числе и локальному InterBase), входящее в поставку Delphi, позволяет создавать таблицы - через посылку SQL-запросов.

Database Desktop не обладает всеми возможностями по управлению SQL-серверными базами данных. Поэтому с помощью Database Desktop удобно создавать или локальные базы данных или только простейшие SQL-серверные базы данных, состоящие из небольшого числа таблиц, не очень сильно связанных друг с другом. Если же необходимо создать базу данных, состоящую из большого числа таблиц, имеющих сложные взаимосвязи, можно воспользоваться языком SQL. Можно записать всю последовательность SQL-предложений в один так называемый скрипт и послать его на выполнение. Конкретные реализации языка SQL незначительно отличаются в различных SQL-серверах, однако базовые предложения остаются одинаковыми для всех реализаций. Практика показывает, что если нет необходимости создавать таблицы во время выполнения программы, то лучше воспользоваться WISQL.

InterBase - это система управления реляционными базами данных, поставляемая корпорацией BORLAND для построения приложений с архитектурой клиент-сервер произвольного масштаба: от сетевой среды небольшой рабочей группы с сервером под управлением Novell NetWare или Windows NT на базе IBM PC до информационных систем крупного предприятия на базе серверов IBM, Hewlett-Packard, SUN и т.п.

В пакет Delphi входит однопользовательская версия InterBase для Windows - Local InterBase. Используя Local InterBase можно создавать и отлаживать приложения, работающие с данными по схеме клиент-сервер, без подключения к настоящему серверу. В дальнейшем потребуется только перенастроить используемый псевдоним базы данных и программа будет работать с реальной базой без перекомпиляции. Кроме того, Local InterBase можно использовать в приложениях для работы с данными вместо таблиц Paradox.

Важной составной частью приложения является вывод данных на печать - получение отчета. В пакет Delphi входит средство для генерации и печати отчетов - ReportSmith. Вы можете объединить отчет с приложениями Delphi. Также, библиотека визуальных компонент Delphi включает специальный компонент TReport. В данном уроке показано, как использовать компоненту TRepor и рассмотрены основные принципы проектирования отчетов в ReportSmith.

Borland ReportSmith является инструментом для получения отчетов и интегрирован в среду Delphi. Отчет может быть добавлен к приложениям Delphi. Отчеты могут быть созданы для SQL БД или локальных БД и не требуют знания сложных команд БД. Интерфейс ReportSmith использует стандартные инструменты Windows типа tool bar, formatting ribbon, и “drag and drop”. Если пользователь уже знаком с интерфейсом стандартных Windows-программ, типа Word for Windows или Quattro Pro for Windows, ему будет “знаком” и интерфейс ReportSmith. ReportSmith предлагает 4 типа отчетов: Табличный, Кросс-таблица(CrossTab), Форма(Form) и Наклейка(Label).

ReportSmith использует концепцию “живых данных”, т.е. работа происходит с настоящими данными все время, а не только тогда, когда запускается просмотр (preview). Кроме этого, ReportSmith легко работает с чрезвычайно большими БД при помощи адаптивной технологии управления памятью. В ReportSmith можно управлять тем, где сохраняется результат выборки данных из БД: в локальный памяти клиентской PC, на жестком диске клиентской PC, или на сервере.

После запуска Delphi в верхнем окне горизонтально располагаются иконки палитры компонент. Если курсор задерживается на одной из иконок, под ней в желтом прямоугольнике появляется подсказка

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

Поскольку в Delphi программа строится визуальным образом, все эти компоненты имеют свое графическое представление в поле форм для того, чтобы можно было бы ими соответствующим образом оперировать. Но для работающей программы видимыми остаются только визуальные компоненты. Компоненты сгруппированы на страницах палитры по своим функциям. К примеру, компоненты, представляющие Windows “common dialogs” все размещены на странице палитры с названием “Dialogs”.

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

В Delphi можно определить свою группу компонент и разместить ее на странице палитры, а если возникнет необходимость, перегруппировать компоненты или удалить неиспользуемые.

Интеллектуальный редактор. Редактирование программ можно осуществлять, используя запись и исполнение макросов, работу с текстовыми блоками, настраиваемые комбинации клавиш и цветовое выделение строк.

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

Инспектор объектов. Этот инструмент представляет из себя отдельное окно, где вы можете в период проектирования программы устанавливать значения свойств и событий объектов (Properties & Events).

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

Навигатор объектов. Показывает библиотеку доступных объектов и осуществляет навигацию по приложению. Можно посмотреть иерархию объектов, прекомпилированные модули в библиотеке, список глобальных имен вашего кода.

Дизайнер меню. Можно создавать меню, сохранить созданные в виде шаблонов и затем использовать в их в любом приложении.

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

Эксперт форм, работающих с базами данных

Эксперт стилей и шаблонов приложений

Эксперт шаблонов форм

В состав RAD Pack входит эксперт для преобразования ресурсов, изготовленных в Borland Pascal 7.0, в формы Delphi. Уже появились эксперты, облегчающие построение DLL и даже написание собственных экспертов

Интерактивная обучающая система. Позволяет более полно освоить Delphi. Она являются не просто системой подсказок, а показывает возможности Delphi на самой среде разработчика.

Delphi это высокопроизводительный инструмент создания приложений. Для запуска Delphi требуется как минимум 386 компьютер с 4MB памяти. Более подходящей машиной будет 486DX 66MHz с 8MB ОЗУ.

Небольшие программы, созданные на Delphi будут работать на любом компьютере. Другими словами, они не требуют того ОЗУ или скорости процессора, что необходимо для среды Delphi. [4].

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

Проектирование обычно поручается человеку (группе лиц) - администратору базы данных (АБД). Им может быть как специально выделенный сотрудник, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.

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

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

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

Чтобы различать представления данных конечными пользователями, программистами и АБД создаются разные уровни моделей данных. Их общая структура представлена на рис. 14.

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

Предметная область - часть реального мира отражённая в базу данных.

Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных.

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

Сущность - любой реальный или не реальный различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром - Москва, Киев и т.д.

Атрибут - поименованная характеристика сущности. Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

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

Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных - это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

При определении инфологической модели необходимо принимать во внимание следующее:

База данных должна удовлетворять актуальным информационным пот-ребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам.

База данных должна обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производи-тельности.

База данных должна удовлетворять выявленным и вновь возникающим требованиям всех пользователей.

База данных должна легко расширяться при реорганизации и расшире-нии предметной области.

База данных должна легко изменяться при изменении программной и аппаратной среды.

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь" или называемая ещё ER-моделью (от англ. Entity-Relationship, т.е. сущность-связь).

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных.

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

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Студент может не "заработать" стипендию, получить обычную или одну из повышенных стипендий. Или, допус-тим, в определенный момент времени один клиент может сделать только один заказ. В этом случае между объектами КЛИЕНТ и ЗАКАЗ устанавливается взаимосвязь «один к одному», обозначаемая одинарными стрелками.

Между данными, хранящимися в объектах КЛИЕНТ и ЗАКАЗ, будет сущест-вовать взаимосвязь, в которой каждая запись в одном объекте будет однозначно указывать на запись в другом объекте. Ни в одном, ни в другом объекте не может существовать записи, не связанной с какой-либо записью в другом объекте.

Второй тип - связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Квартира может пустовать, в ней может жить один или несколько жильцов. Или, например, в определенный момент времени один клиент может стать обладателем несколь-ких моделей автомобилей, при этом несколько клиентов не могут являться обладателями одного автомобиля. Взаимосвязь «один ко многим» можно обоз-начить с помощью одинарной стрелки в направлении к «одному» и двойной стрелки в направлении ко «многим» .В этом случае одной записи данных первого объекта (его часто называют родительским или основным) будет соответствовать несколько записей второго объекта (дочернего или подчиненного). Взаимосвязь «один ко многим» очень распространена при разработке реляционных баз данных.

Третий тип - связь МНОГИЕ-К-ОДНОМУ (М:1): одному представителю сущности B соответствуют 0, 1 или несколько представителей сущности А.

В принципе нет никакой разницы между связью ОДИН-КО-МНОГИМ и МНОГИЕ-К-ОДНОМ, т.к. между двумя сущностями возможны связи в обоих направлениях и всё зависит от того с какими сущностями связаны данные.

Четвёртый тип - связь МНОГИЕ-КО-МНОГИМ (N:М): одному представителю сущности B соответствуют 0, 1 или несколько представителей сущности А и одновременно одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Это также обусловлено тем, что между двумя сущностями возможны связи в обоих направлениях.

Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК, то существует четыре возможных представления такой связи:

Или например каждый продавец может обслуживать нескольких клиентов. С другой стороны, приобретая автомобили в различное время, каждый клиент вполне может быть обслужен различными продавцами. Между объектами КЛИЕНТ и ПРОДАВЕЦ существует взаимосвязь «многие ко многим». Такая взаимосвязь обозначается двойными стрелками.

Характер связей между сущностями не ограничивается перечисленными. Существуют и более сложные связи:

множество связей между одними и теми же сущностями

(пациент, имея одного лечащего врача, может иметь также несколько врачей-консультантов; врач может быть лечащим врачом нескольких пациентов и может одновременно консультировать несколько других пациентов);

тренарные связи:

связи более высоких порядков, семантика (смысл) которых иногда очень сложна.

В приведенных примерах связей не показаны атрибуты сущностей и ассоциаций во всех ER-диаграммах. Так, ввод лишь нескольких основных атрибутов в описание брачных связей значительно усложнит ER-диаграмму (рис. 2.1,а). В связи с этим язык ER-диаграмм используется для построении небольших моделей и иллюстрации отдельных фрагментов больших. Чаще же применяется менее наглядный, но более содержательный язык инфологического моделирования (ЯИМ), в котором сущности и ассоциации представляются предложениями вида:

СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n)

АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...]

(атрибут 1, атрибут 2, ..., атрибут n)

где S - степень связи, а атрибуты, входящие в ключ, должны быть отмечены с помощью подчеркивания.

Так, рассмотренный выше пример множества связей между сущностями, может быть описан на ЯИМ следующим образом:

Врач (Номер_врача, Фамилия, Имя, Отчество, Специальность)

Пациент (Регистрационный_номер, Номер койки, Фамилия,

Имя, Отчество, Адрес, Дата рождения, Пол)

Лечащий_врач [Врач 1, Пациент M]

(Номер_врача, Регистрационный_номер)

Консультант [Врач M,Пациент N]

(Номер_врача, Регистрационный_номер).

Для примера ER-диаграмма базы данных "Питание" показана на рис.16, а модель на языке ЯИМ имеет следующий вид:

Блюда (БЛ, Блюдо, Вид)

Продукты (ПР, Продукт, Калорийность)

Поставщики (ПОС, Город, Поставщик) [Город]

Состав [Блюда M, Продукты N] (БЛ, ПР, Вес (г))

Поставки [Поставщики M, Продукты N] (ПОС, ПР, Дата_П, Цена, Вес (кг))

Города (Город, Страна)

Рецепты (БЛ, Рецепт) {Блюда}

Расход (БЛ, Дата_Р, Порций) {Блюда}

В этих моделях Блюдо, Продукт и Поставщик - наименования, а БЛ, ПР и ПОС - цифровые коды блюд, продуктов и организаций, поставляющих эти продукты.

Существует ещё наиболее распространенная модификация ER-диаграмм для представления инфологической модели баз данных - "Таблица-связь", пример использования которого приведен на рис. 16. В нем все сущности изображаются одностолбцовыми таблицами с заголовками, состоящими из имени и типа сущности. Строки таблицы - это перечень атрибутов сущности, а те из них, которые составляют первичный ключ, располагаются рядом и обводятся рамкой. Связи между сущностями указываются стрелками, направленными от первичных ключей или их составляющих. Именно этот тип диаграмм будет использоваться при построении инфологической модели базы данных, разрабатываемой в данной дипломной работе.

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

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

При разработке даталогической модели, кроме требований предъявляемых для построения инфологической модели, предъявляются дополнительные требования:

Загруженные в базу данных корректные данные должны оставаться корректными.

Данные до включения в базу данных должны проверяться на достовер-ность.

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

Разрешение проблем, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

Способы обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

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

Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

База данных организованна в популярном формате локальных баз данных 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) в задаче реализации готовой продукции формируются квитанции и накладные на выдачу муки клиентам.

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

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

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

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

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

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

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