Разработка базы данных для оформления заявок клиентов телефонной сети на примере ФГУП «ЦАГИ»

Схема 5. Отображение связи КОНТРАКТ – ЗАКАЗЧИК.

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

Многие ко многим (n : n). В этом случае каждая из ассоциированных сущностей может быть представлена любым количеством экземпляров. Пусть на рассматриваемом нами предприятии для выполнения каждого контракта создается рабочая группа, в которую входят сотрудники разных отделов. Поскольку каждый сотрудник может входить в несколько (в том числе и ни в одну) рабочих групп, а каждая группа должна включать не менее одного сотрудника, то связь между сущностями СОТРУДНИК и РАБОЧАЯ_ГРУППА имеет степень n : n (см. схему 6).

Схема 6. Отображение связи СОТРУДНИК  – РАБОЧАЯ_ГРУППА.

Если существование сущности x зависит  от существования сущностиy, то x называется зависимой сущностью (иногда сущность x называют «слабой», а «сущность» y - сильной).

В качестве примера рассмотрим связь  между ранее описанными сущностями РАБОЧАЯ_ГРУППА и КОНТРАКТ. Рабочая  группа создается только после того, как будет подписан контракт с  заказчиком, и прекращает свое существование  по выполнению контракта. Таким образом, сущность РАБОЧАЯ_ГРУППА является зависимой  от сущности КОНТРАКТ. Зависимую сущность будем обозначать двойным прямоугольником, а ее связь с сильной сущностью  линией со стрелкой (см. схему 7).

Схема 7. Отображение связи РАБОЧАЯ_ГРУППА – КОНТРАКТ.

Заметим, что кардинальность связи  для сильной сущности всегда будет (1,1). Класс принадлежности и степень  связи для зависимой сущности могут быть любыми. Предположим, например, что рассматриваемое нами предприятие  пользуется несколькими банковскими  кредитами, которые представляются набором сущностей: КРЕДИТ(НОМЕР_ДОГОВОРА,СУММА, СРОК_ПОГАШЕНИЯ, БАНК). По каждому кредиту должны осуществляться выплаты процентов и платежи в счет его погашения. Этот факт представляется набором сущностей ПЛАТЕЖ(ДАТА, СУММА) и набором связей «осуществляется по». В том случае, когда получение запланированного кредита отменяется, информация о нем должна быть удалена из базы данных. Соответственно, должны быть удалены и все сведения о плановых платежах по этому кредиту. Таким образом, сущность ПЛАТЕЖ зависит от сущности КРЕДИТ (см. схему 8).

Схема 8. Отображение связи ПЛАТЕЖ – КРЕДТИТ.

 

Глава 2. Проектно-программная часть

2.1. Создание базы данных

2.1.1. Определение модели данных

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

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

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

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

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

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

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

2.1.2. Инфологическое моделирование предметной области

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

Создание этой модели является первым шагом процесса формализации. В отличие  от представления на естественном языке  она в основном исключает неоднозначность  за счет использования средств формальной логики.

Одно из главных понятий инфологической модели - объект. Это понятие связано  с событиями: возникновение, исчезновение и изменение.

Объекты могут быть атомарными или  составными.

Атомарный объект- это объект определенного  типа, дальнейшее разложение которого на более мелкие объекты внутри данного  типа невозможно.

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

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

Инфологическая модель позволяет  выделить три категории фактов: истинные, значимые и ложные.

С одной стороны, это обеспечивает модели дополнительную гибкость, с  другой - создает определенные сложности.

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

Цель инфологического моделирования - формализация объектов реального  мира предметной области и методов  обработки информации в соответствии с поставленными задачами обработки  и требованиями представления данных естественными для человека способами  сбора и представления информации.

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

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

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

Основными компонентами инфологической модели являются:

• описание предметной области;

• описание методов обработки;

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

Логическая структура базы данных определяет:

• таблицы и их имена, также называемые сущностями (entities);

• имена полей, также называемые атрибутами (attributes) каждой таблицы;

• характеристики полей, например уникальность их значения и допустимость значений NULL, а также тип данных, хранимых в поле;

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

• связи между таблицами. Записи в таблице могут зависеть от одной  или нескольких записей другой таблицы. Такие отношения между таблицами  называются связями. Связь определяется следующим образом: поле или несколько  полей одной таблицы, называемое внешним ключом, ссылается на первичный  ключ другой таблицы.

 

2.1.3  Выбор СУБД

 

После построения ИЛМ необходимо выбрать СУБД, с помощью которой  мы будем управлять нашими БД.

На сегодняшний  день существует много разнообразных  систем управления базами данных. Это  такие СУБД как Paradox, FoxPro, Clipper, Access и др. Для работы с большинством из них требуются достаточно глубокие знания данной СУБД и опыт программирования.

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

В Microsoft Access присутствует язык программирования Visual Basic, который позволяет создавать массивы, свои типы данных, контролировать работу приложений. MS Access имеет один из самых лучших наборов визуальных средств разработки и представления информации среди аналогичных программных продуктов.

Одно  из основных преимуществ MS Access – интеграции с популярным офисным пакетом Microsoft Office.

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

Встроенный язык запросов SQL позволяет максимально гибко  работать с данными и значительно  ускоряет доступ к внешним данным.

Access воспринимает большое количество форматов данных, включая файловые структуры других СУБД. Поэтому приложение в Access может импортировать из текстовых файлов или электронных таблиц и экспорт в них: предоставлять прямой доступ и обновлять файлы Paradox, FoxPro и других БД. Можно также импортировать данные из этих файлов в таблицы Access.

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

Архитектура Access называет объектами все, что может иметь имя. В БД Access основными объектами являются таблицы, запросы, формы, отчеты, макросы и модули. Термин БД обычно относится только к файлам, в которых хранятся данные. В Access БД включает  все объекты, связанные с хранимыми данными, в том числе и те, которые определяются для автоматизации работы (см. Табл. 2.1.).

                                                                               Таблица 2.1.

Компоненты  СУБД Access.

Объект	Описание
Таблица	Содержит информацию об объектах. Поля (столбцы) хранят характеристики объектов, а каждая запись (строка) содержит сведения об объекте.
Запрос	Фиксирует нужные данные из одной или  нескольких таблиц. Для запроса можно  использовать запрос по образцу или  инструкцию SQL –запросы на выборку  и обновление данных.
Форма	Отражает требования к данным таблиц или запросов. Формы можно распечатать. С помощью формы можно запустить  макрос или VBA.
Отчет	Объект форматирования, вычисления итогов и печати данных.
Макрос	Описание действий Access в ответ на событие. Макрос открывает другую форму, может проверять поля при изменении его содержимого, открывать таблицы, запросы, просмотр или печать, запустить другой макрос или процедуру VBA.
Модуль	Программа на языке Visual Basic для приложений, обнаружения ошибки, которые не обнаруживает макрос. Модули могут быть независимыми объектами, содержащими функции, вызываемые из любого приложения или отчета для реакции на события.