Базы данных по анкетам детей, оставшихся без попечения родителей для ОГОУ “Центра психолого-медико-социального сопровождения”

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

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

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

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

2.3.1. Проектирование инфологической модели

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

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

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

      Проектирование  инфологической (концептуальной) модели проведено с помощью метода «Сущность-связь».

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

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

      Между объектами существуют связи. В дальнейшем будут рассматриваться только бинарные связи.

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

      В соответствии с этим определением существуют бинарные связи  степеней:

• 1: 1 (каждый экземпляр одного объекта связан не более чем с одним экземпляром другого), обозначается <----->;
• 1: N (каждый экземпляр одного объекта связан с несколькими экземплярами   другого, но каждый экземпляр второго объекта связан не более чем с одним экземпляром первого), обозначается <---->>;
• M: N (каждый экземпляр первого объекта связан с несколькими экземплярами второго и наоборот), обозначается <<---->>.

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

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

      Будем записывать возможные варианты классов  принадлежности в виде

О-О, О-Н, Н-О, Н-Н.

      Указание  * вместо О или Н означает, что класс принадлежности    несущественен.

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

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

        ПРАВИЛО 1. Если степень связи 1:1 и классы принадлежности О-О, то требуется только одно отношение, ключом которого может быть ключ любого объекта;

        ПРАВИЛО 2. Если степень связи 1:1 и классы принадлежности О-Н, то необходимо построение двух отношений. Каждому объекту соответствует одно отношение, при этом ключ объекта является ключом соответствующего отношения. Кроме того, ключ второго объекта добавляется в качестве атрибута в первое отношение;

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

        ПРАВИЛО 4. Если степень связи 1:N и классы принадлежности *-О, то достаточным является использование двух отношений, соответствующих объектам, причем ключами будут ключи объектов, но дополнительно ключ первого объекта должен быть атрибутом второго отношения;

        ПРАВИЛО 5. Если степень связи 1:N и классы принадлежности *-Н, то необходимо построение трех отношений: по одному на каждый объект, причем ключи отношений совпадают с ключами объектов, и связующего отношения,  ключом которого будет комбинация ключей объектов;

        ПРАВИЛО 6. Если степень связи M:N, то необходимо построение трех  отношений: по одному на каждый объект, причем ключи отношений совпадают с ключами объектов, и связующего отношения, ключом которого будет комбинация ключей объектов.

      После этого все неключевые атрибуты распределяются по отношениям (см. приложение 4).

2.3.2. Проектирование логической и физической модели

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

     Описание  информационной модели базы данных проведено  с использованием CASE-средства ERwin.

     Реализация  моделирования в ERwin базируется на теории реляционных баз данных и на методологии IDEF1X. Методология IDEF1X была разработана для ВВС США и теперь используется, в частности, в правительственных, аэрокосмических и финансовых учреждениях, а также в большом числе частных компаний.

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

        1) определение сущностей; 

        2) определение зависимостей между сущностями;

        3) задание первичных  и альтернативных ключей;

        4) определение атрибутов сущностей.

     ERwin создает визуальное представление  (модель данных) для решаемой задачи.

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

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

     В качестве системы управления БД выбран InterBase 6.5. Пакет Erwin преобразовал логическую модель БД в физическую модель для данной СУБД.

     При построении логической и физической модели (последняя привязана к  конкретной системе управления базами данных СУБД InterBase) введем в качестве первичного ключа, однозначно определяющего каждую запись сущности, поле id_X, где X – сокращение от названия сущности.

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

     Построение  логической и физической моделей проводилось с использованием CASE-средства ErWin (см. рис. 10-11).

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

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

      Рисунок 10. Логическая модель базы данных 

      Рисунок 11. Физическая модель базы данных

2.4. Описание серверной части клиент-серверного приложения

     При помощи CASE-средства ErWin сгенерирован SQL скрипт БД, (см. приложение 5).

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

Рисунок 12. Генератор первичного ключа, созданный  в IBExpert

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

     Генератор – это механизм для создания уникальных значений первичных ключей при добавлении строк к таблицам.

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

2.5. Описание клиентской части

клиент-серверного приложения

     Клиентская  часть клиент-серверного приложения выполнена с использованием среды  визуального программирования Borland Delphi 7 (см. приложение 6).

     Структура получившего клиент-серверного приложения (см. рис. 13).

 

 
 
 

Рисунок 13. Структура клиент-серверного приложения

     Все не визуальные компоненты объединены в модуль данных «Data Module» (см. рис. 14).

Рисунок 14. Модуль данных с не визуальными компонентами

     При запуске системы на экране отображается форма авторизации пользователя (см. рис. 15).

Рисунок 15. Форма авторизации пользователей

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

Рисунок 16. Главное окно приложения

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

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

2.6. Проектирование тестов и тестирование

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