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

Ядром инфологической модели является описание объектов предметной области и связей между ними (сущность - связь). Для описания инфологической модели используют как языки аналитического(описательного) типа, так и графические средства. Графические средства являются более наглядными и простыми для восприятия. Для построения модели данных используется удобный инструмент - ERWin. ERwin - средство разработки структуры базы данных (БД). Обычно разработка модели базы данных состоит из двух этапов: составление логической модели и создание на ее основе физической модели. ERwin полностью поддерживает такой процесс, он имеет два представления модели: логическое (logical) и физическое (physical). Таким образом, разработчик может строить логическую модель базы данных, не задумываясь над деталями физической реализации, т.е. уделяя основное внимание требованиям к информации и бизнес-процессам, которые будет поддерживать будущая база данных.

При проектировании структуры новой базы данных определяют сущности (объекты, явления) предметной области, которые должны найти свое отражение в базе данных. Цель инфологического этапа проектирования состоит в получении семантических (концептуальных) моделей, отражающих предметную область и информационные потребности пользователей. В качестве инструмента для построения семантических моделей данных на этапе инфологического проектирования является неформальная модель "Сущность-Связь" (ER-модель - Entity-Relationship). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов.

Основными понятиями ER-модели являются сущность, связь и атрибут.

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

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

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

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

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

Среди бинарных связей существуют три фундаментальных вида связи: один-к-одному (1: 1), один-ко-многим (1: M), многие-ко-многим (M: M). Связь один-к-одному (1: 1) существует, когда один экземпляр одной сущности связан с единственным экземпляром другой сущности. Связь один-ко-многим (1: M) имеет место, когда один экземпляр одной сущности связан с одним или более экземпляром другой сущности и каждый экземпляр второй сущности связан только с одним экземпляром первой сущности. Связь многие-ко-многим (М: N) существует, когда один экземпляр одной сущности связан с одним или более экземпляром другой сущности и каждый экземпляр второй сущности связан с одним или более экземпляром первой сущности.

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

Все связи требуют описания. Описание должно обеспечивать:

· идентификатор связи;

· формулировку имен связи с точки зрения каждой участвующей сущности;

· вид связи (множественность и условность);

· формулировку того, как связь была формализована.

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

Все сущности относятся к одному из четырех классов:

· стержневые;

· ассоциативные;

· характеристические;

· обозначающие.

Стержневая сущность (стержень) представляет собой независимую сущность.

Ассоциативная сущность (ассоциация) - это сущность, формализующая связь вида M: N между двумя или более сущностями или связь вида 1: 1 между экземплярами сущностей.

Характеристическая сущность (характеристика) представляет собой сущность, формализующую связь вида 1: M или 1: 1. Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности.

Обозначающая сущность (обозначение) - это сущность, также формализующая связь вида 1: M или 1: 1 между двумя сущностями, но отличающаяся от характеристики тем, что не зависит от обозначаемой сущности.

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

В результате анализа были выделены 8 объектов, которые описывают данную предметную область. Это:

Сущность “Заявки”. Она включает в себя основные сведения о заявках.

Сущность “Контрагенты”. Она включает в себя сведения о клиентах.

- Сущность “Отделы”, которая включает в себя сведения о всех отделах.

- Сущность “Простой Ремонт”. Она содержит сведения о простом ремонте. Простой ремонт-ремонт или замена какой-либо одной запчасти

- Сущность “Работники” содержит сведения о работках и его принадлежность к отделу.

- Сущность “Ремонт Узлов” содержит сведения о возможных ремонтируемых узлах, стоимость ремонта.

-Сущность “Сложный Ремонт” содержит заявку на сложный ремонт и сведения о ремонтируемом узле.

- Сущность “Состав Ремонта”. Она содержит сведения о виде ремонта, ремонтируемом узле и работнике, выполняющем данный вид работ.

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

Различают идентифицирующую связь и не идентифицирующую связь. При установлении не идентифицирующей связи дочерняя сущность остается независимой. Экземпляр сущности родителя может существовать безотносительно к какому-либо экземпляру дочерней сущности.

В данной разработке все объекты связаны идентифицирующей связью.

Выявление сущностей базы данных

Ссылочная целостность для всех связей одинакова: любые операции с дочерней сущностью никак не повлияют на родительскую. При удалении или обновлении родительской сущности - дочерние сущности удаляются или обновляются каскадом. При добавлении новой записи в родительские сущности реакция отсутствует.

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

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

ER-диаграмма логического уровня

ER-диаграмма логического уровня

Даталогическое проектирование

1.2.1. Разработка и реализация информационных потоков

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

13

Рисунок 1.4. - Схематическое изображение информационных потоков.

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

1.2.2. Подключение к базе данных по технологии ADO

Для доступа к базе данных мы используем ADOConnection. В отличие от других способов доступа к БД в нашем случае для подключения нет возможности использовать привычные свойства DataBaseName и AliasName. При использовании технологии ADO вместо этих свойств используются строки соединения (connection string) и все параметры соединения отображаются и настраиваются именно в них. Существует два основных способа настройки строки соединения - вручную и в специальном диалоговом окне. При собственноручной настройке легко ошибиться в параметрах. И поэтому, большинство разработчиков идет по пути использования редактора строки соединения. Единственный, на наш взгляд, недостаток такого подхода - это привязка к конкретному пути к файлу базы данных. Чтобы избежать недостатков обоих подходов мы пошли по среднему варианту - для первого подключения к базе данных при разработке программы в инспекторе объектов мы использовали редактор строки соединения. И получили правильную строку. Затем, проанализировав ее содержимое, мы увидели в какой части строки хранится информация об имени и пути к файлу базы данных. Теперь, используя элементарные операции для работы со строковым типом данных в Delphi мы можем заменять эту часть строки соединения на любой другой нужный нам файл данных. Это выполняется у нас двумя способами. Первый - автоматически при запуске программы определяется текущий каталог и первое подключение осуществляется к файлу базы данных, который находится в том же каталоге, где и наша программа. Имя файла базы данных (за исключением его расширения) должно совпадать с именем программы. Реализация этого приведена на листинге 1.1. А второй способ - это возможность пользователя нашей программы подключиться к необходимому ему файлу (разумеется, структура базы данных должна совпадать) путем использования диалога выбора файла в форме настройки параметров. (см. рис.1.5, 1.6)

Листинг 1.1. - Фрагмент программы, реализующий автоподключение к БД

procedure TForm5. BitBtn1Click(Sender: TObject);

begin

// Переподключение к БД с заданной строкой подключения

dm. ADOConnection1. Close;

dm. ADOConnection1. ConnectionString: =edit1. Text+edit2. Text+ edit3. Text;

end;

procedure TForm5. FormActivate(Sender: TObject);

begin

// Автоматическое определение имени файла БД и пути к нему

Edit2. Text: = ChangeFileExt(application. ExeName,'. mdb');

BitBtn1Click(Sender);

end;

Рисунок 1.5. - Форма ввода параметров

Рисунок 1.6. - Диалог выбора файла базы данных

1.2.3. Разработка универсальной формы для просмотра/редактирования таблиц базы данных

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

Не создавать полей в компоненте ADOTable на этой форме.

Не создавать столбцов в компоненте DBGrid, который подключен через DataSource к ADOTable на этой форме.

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

Записывать название таблицы в заголовке формы при ее открытии.

Для обеспечения возможности работы в режиме просмотра мы должны только установить свойство ReadOnly компонента ADOTable в состояние True. С учетом всего вышесказанного, вызов универсальной формы должен осуществляться так, как на Листинге 1.2:

Листинг 1.2. - Фрагмент модуля данных, осуществляющий вызов формы для просмотра/редактирования таблиц базы данных.

procedure Tdm. ShowSlovar (aname: string; RO: boolean=true);

var

f: TForm4;

begin

// Метод реализующий вызов формы просмотра/редактирования таблиц

// aname - имя таблицы

// RO - режим доступа

f: =TForm4. Create(self);

f. ADOT. TableName: =aname;

f. Caption: =aname;

if RO then

begin

f. ADOT. ReadOnly: =RO;

f. Caption: =f. Caption+' (только чтение) ';

end;

f. ShowModal;

f. Free;

end;

Для реализации возможности сортировки мы используем локальные индексы. Это продемонстрировано на Листинге 1.3.

Листинг 1.3. - Фрагмент программы для сортировки таблиц

procedure TForm3. DBGrid1TitleClick(Column: TColumn);

var i: integer;

begin // Сортировка

// Убираем расскраску стобцов

for i: =0 to DBGrid1. Columns. Count-1 do

begin

DBGrid1. Columns. Items [i]. Color: =clwhite;

end;

Column. Color: =clLime;

if ADOT. IndexFieldNames=Column. Field. FieldName

then

begin

// Если была прямая сортировка, устанавливаем обратную

Column. Color: =clLime;

ADOT. IndexFieldNames: =Column. Field. FieldName+' DESC'

end

else

begin

// Если не было сортировки по этому полю (или обратная)

// устанавливаем прямую сортировку

Column. Color: =clAqua;

ADOT. IndexFieldNames: =Column. Field. FieldName;

end;

end;

В результате мы получили форму, пример использования которой приведен на рис.1.7.

Рисунок 1.7. - Внешний вид универсальной формы при работе с таблицей РемонтУзлов в режиме просмотра.

Заключение

В данной работе была спроектирована и реализована информационная - справочная система "Автосервис", обеспечивающая:

ввод, редактирование и просмотр данных;

ответы на запросы пользователя;

поиск необходимой информации;

формирование отчетов.

Освоены навыки проектирования баз данных методом ER-диаграмм.

Реализация системы проводилась с использованием инструментального средства разработки приложения Microsoft Access2003/XP и языка программирования Object Pascal.

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

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

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

1. Хохлачев Е.Н. "Теоретические основы создания и применения АСУ", Москва, Министерство обороны, 1987г.

2. Абчук В.А., Лифшиц А.Л., Федулов А.А., Куштина Э.И. "Автоматизация управления", Москва "Радио и связь", 1984г.

3. Мамиконов А. Г. "Проектирование АСУ" (учебник для вузов), Москва "Высшая школа".

4. Ахаян Р., Горев А., Макашарипов С. "Эффективная работа с СУБД", Санкт-Петербург, 1997г.

5. Гончаров A. "Access 2000 в примерах" Санкт-Петербург, 1997г.

6. Фленов М.Е. Библия Delphi. -2-e изд., БВХ-Петербург, 2008 г.