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

---

Страница:   1   2   3   4

---

3.1 Решения по аппаратно-программному обеспечению

Проект будет реализовываться на персональном компьютере стандартной конфигурации с установленной операционной системой Windows XP. Для реализации проекта будет использоваться среда разработки Delphi 7 и Microsoft Access.

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

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

Требования для монитора:

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

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

Как правило, персональный компьютер работает под управлением операционной системы. Также, Microsoft Access разработана под операционную систему Microsoft Windows. Windows – повсеместно распространенная, стандартная многозадачная операционная система для современных IBM – совместимых персональных компьютеров.

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

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

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

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

В системе управления СУБД MS Access в рамках таблиц действуют механизмы определения и организации контроля стандартных правил целостности данных в реляционных моделях.

Для создания программы была взята среда разработки Delphi 7.

Delphi 7 содержит развитые библиотеки и инструменты для создания приложений электронного бизнеса и Web — сервисов, полностью интегрирует соответствующие технологии и качественно повышает производительность разработчиков, предоставляя все необходимое для исследования вопросов перехода на Microsoft .NET.

При помощи включенного в комплект поставки Kylix 3 для Delphi разработчики могут переносить свои приложения на Linux, повышая отдачу своих инвестиций и расширяя спектр платформ, на которых доступны их приложения. Интегрируя ведущие приложения разработки в единый и легкий в использовании пакет, Delphi 7 сокращает жизненный цикл разработки приложений и ускоряет вывод создаваемых с его помощью продуктов на рынок ПО.

Ключевые возможности, появившиеся в Delphi 7:

• предварительный вариант средств для работы с Microsoft .NET Framework

Kylix 3.0 для Linux в составе пакета;

• бесплатная лицензия на развертывание многозвенных приложений (которая до этого была платной), использующих технологию DataSnap (прежнее название — MIDAS);
• полное решение проектирования и развертывания корпоративных приложений по технологии Model Driven Architecture (MDA);
• мощные и удобные средства разработки WEB-приложений;
• средства создания качественных кроссплатформенных отчетов Rave Reports;
• среда моделирования ModelMake.

Delphi 7 обладает возможностями проектирования и развертывания корпоративных приложений. Это позволяет разработчикам быстрее воспользоваться преимуществами разработки корпоративных приложений от концепции до коммерческой версии при помощи новой системы проектирования UML и технологии Model Driven Architecture (MDA).

Визуальная среда WEB-разработки Delphi 7 позволяет визуально строить WEB-приложения и кардинально уменьшает обычные временные затраты, связанные с созданием серверной составляющей приложений, включая управление сессиями в многопользовательском режиме доступа.

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

Kylix 3 в составе Delphi 7 является первой высокопроизводительной визуальной интегрированной средой разработки (IDE), предназначенной для быстрого создания приложений баз данных, программ с графическим пользовательским интерфейсом (GUI), Internet-приложений и WEB-сервисов для операционной системы Linux.

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

Новые правила лицензирования Delphi 7 на развертывание многозвенных приложений (DataSnap) дают возможность беспрепятственно масштабировать одноуровневые и клиент/серверные приложения до многоуровневых без дополнительных затрат, связанных с развертыванием систем [1].

Delphi 7 включает также поддержку тем Windows XP, позволяя разработчикам создавать приложения, пользующиеся возможностями тем пользовательского интерфейса Windows XP.

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

3.2 Концептуальный уровень проектирования

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

3.2.1 Основные понятия

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

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

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

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

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

3.2.2 Описание предметной области

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

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

В теории БД принято говорить о концептуальном, или информационно — логическом, моделировании предметной области. Центральным понятием является понятие концептуальной схемы (модели) предметной области.

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

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

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

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

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

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

Общее количество сформулированных в отдельном локальном представлении должно быть ограниченным.

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

Для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности служит атрибут сущности.

Разновидности атрибутов:

• идентифицирующие
• связывающие
• описывающие

Выделим следующие сущности с предполагаемыми атрибутами, опираясь на предметную область, рассмотренную ранее.

1. Сущность cookbook Атрибуты: id

• title
• howto
• kind
• type

2. Сущность cookbook_food Атрибуты: id

• cbit
• pfid
• number

3. Сущность food Атрибуты: id

• title
• type

4. Сущность holidays Атрибуты: id

• title
• description
• kind

5. Сущность holylist                                     Атрибуты: id

• description

3.2.4 Построение концептуальной схемы

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

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

Ключи обычно используют для достижения следующих целей:

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

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

3) ускорения работы с кортежами отношения;

4) организации связывания таблиц.

Критерии выбора первичного ключа:

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

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

Суть связывания состоит в установлении соответствия полей связи ос­новной и дополнительной таблиц. Поля связи основной таблицы могут быть обычными и ключевыми. В качестве полей связи подчиненной таблицы чаще всего используют ключевые поля.

3.3 Логический уровень проектирования

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

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

3.3.1 Краткий обзор логических структур существующих моделей данных

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

Выделяют: иерархическую, сетевую, реляционную и объектно-ориентированную модели данных.

Иерархическая БД представляет собой упорядоченную совокупность экземпляров данных типа «дерево» (деревьев), содержащих экземпляры типа «запись» (записи). Часто отношения родства между типами перено­сят на отношения между самими записями. Поля записей хранят собствен­но числовые или символьные значения, составляющие основное содержание БД. Обход всех элементов иерархической БД обычно производится сверху вниз и слева направо.

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

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

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

3.3.2 Сравнительная характеристика моделей баз данных

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

В связи с этим возникает ряд проблем, основными из которых являются:

1) преобразование моделей данных;

2) выбор модели данных СУБД.

Таблица 3.1. Сравнительная характеристика моделей баз данных

3.3.3 Требования к эксплуатационным характеристикам

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

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

1. Установление многосторонних связей.

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

2. Производительность.

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

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

3. Минимальные затраты.

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

4. Минимальная избыточность.

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

5. Возможности поиска.

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

6. Целостность.

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

7. Безопасность.

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

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

8. Простота использования.

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

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

3.3.4 Обоснование выбора СУБД

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

На самом деле критериев значительно больше: стоимость, про­изводительность, не избыточность и т. д.

На выбор влияет и множество факторов:

1) типы элементов данных;

2) интерфейс пользователя;

3) структура и отношения данных; способы манипулирования данными;

4) целостность БД и защита данных;

5) поддержка программная и техническая;

6) коммерческая поддержка;

7) критерии качества (надежность, точность, соответствие промышленным стандартам);

8) возможности роста и развития.

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

В силу сложности задачи выбора СУБД ее целесообразно решать в два этапа: выбор модели данных; выбор СУБД в рамках принятой модели данных.

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

Для баз данных, реализуемых на суперЭВМ, иногда называемых мейнфреймами, самым важным требованием, предъявляемым к БД, является быстродействие. В силу этого предпочтительным является использование иерархической модели данных или ее разновидности — многомерной модели данных. По тем же причинам для хранилищ данных предпочтительна многомерная модель.

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

Объектно-ориентированные модели данных только начинают использовать в России. В настоящее время фактически единственной СУБД такого класса является САСНЕ.

Объектно-реляционные СУБД используют преимущественно гибридную разновидность.

В этих условиях задача выбора СУБД (для ПК) для построения операционных БД сводится практически к выбору среди реляцион­ных СУБД.

Сравнительные характеристики СУБД приведены в таблице 3.2

Таблица 3.2. Сравнительная характеристика некоторых реляционных СУБД

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

• Выбрать СУБД, подходящие по их техническим характеристикам (прежде всего — по объему данных в разрабатываемой базе данных).
• Из получившегося набора СУБД следует отобрать:

а) по категории конечного пользователя (непрограммист; имеющий квалификацию в программировании; программист; администратор БД);

б) по развитию (удобству) интерфейса СУБД;

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

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

д) по характеристикам формирования распределенной БД и групповой работе с БД (прежде всего – режима клиент — сервер);

е) по поддержке стандартных интерфейсов связи с БД – через язык SQL и приложение ODBC;

ж) по видам блокировки;

к) по имиджу фирмы – разработчика СУБД.

В ряде случаев используют понятие «производительность», т.е. быстродействие БД. Она предполагает оптимизацию процеду­ры запроса, которая проводится далеко не во всех СУБД. В частности, такая процедура реализована в СУБД FохРго.

Для выбора по этому параметру необходимы данные испытаний по специальным тестам. Производительность оценивается в количестве транзакций в секунду на стандартных операциях обновления (при одинаковых объемах данных). К сожалению, результаты такого тестирования публикуются редко [30].

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

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

СУБД Access позволяет поддерживать ссылочную целостность, задавать ограничения на поля, используется язык структурированных запросов SQL.

В Access имеются основные типы данных: счетчик, числовой, текстовый, логический, денежный, дата/время.

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

3.3.5 Реляционная модель данных

В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда, где, вероятно, впервые был применен термин «реляционная модель данных».

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

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

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

Заголовок состоит из такого фиксированного множества атрибутов A1, A2, …, An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,…,n).

Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит, в свою очередь, из множества пар атрибут-значение (Ai:Vi), (i=1,2,…,n). По одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, а степени n – n-арным.

Кардинальное число или мощность отношения – это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, …, An. Говорят, что множество атрибутов K=(Ai, Aj, …, Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:

Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, …, Ak.

Минимальность: ни один из атрибутов Ai, Aj, …, Ak не может быть исключен из K без нарушения уникальности.

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

3.3.6 Целостность реляционной модели

Вопросы безопасности и целостности — одна из важнейших сторон работы СУБД.

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

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

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

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

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

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

• пользователь имеет возможность работы (но не модификации) с объектом, если уровень его допуска больше или равен уровню доступа объекта;
• пользователь имеет возможность модифицировать объект, если уровень его допуска равен уровню доступа объекта.

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

Обычно в файле журнала хранится следующая информация:

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

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

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

Традиционно различают два вида ограничений целостности: немедленно проверяемые и откладываемые. К немедленно проверяемым ограничениям целостности относятся такие ограничения, проверку которых не имеет смысла откладывать на более поздний период. Примером такого ограничения, проверку которого откладывать бессмысленно, являются ограничения домена — оценка по экзамену не может быть менее 1 и более 5 или возраст преподавателя не может превышать 100 лет. Более сложным ограничением, проверку которого невозможно отложить, является следующее: студент не может сдавать экзамен и получить оценку, если у него к этому моменту не сданы все зачеты. Немедленно проверяемые ограничения целостности соответствуют уровню отдельных операторов языкового уровня СУБД. При их нарушениях не производится откат транзакции, а лишь отвергается соответствующий оператор.

Откладываемые ограничения целостности — это ограничения на БД, а не на какие-либо отдельные операции.

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

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

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

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

В общем случае ограничение целостности должно содержать три основные части:

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

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

Различают четыре типа ограничений целостности:

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

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

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

3.3.7 Математическое описание реляционной модели

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

<Имя отношения> (<ключ>, <Имя атрибута 1>, …, < Имя атрибута N>).

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

Определение доменов:

1) Отношение cookbook (id, title, howto, kind, type);

Dom(id) = {0<№r10000}, где №r – номер рецепта по порядку;

Dom(title) = {Nr| char(Nr)}, где char(Nr) – предикат, возвращающий значение «истина», если Nr- строка символов длинной не более 150, где Nr – название рецепта;

Dom(howto) = {Sp| char(Sp)}, где char(Sp) — предикат, возвращающий значение «истина», если Sp — строка символов длинной не более 255, где Sp —  способ приготовления рецепта;

Dom(kind) = {0<Vp10000}, где Vp – вид введенного дня;

Dom(type) = {Nr| Tp(Nr)}, где char(Tp) – предикат, возвращающий значение «истина», если Tp — строка символов длинной не более 255, где Tp – тип рецепта;

2) Отношение cookbook_food (id, cbit, pfid, number);

Dom(id) = {0<№pr10000}, где № pr – номер по порядку;

Dom(cbit) = {0<№r1000}, где №r – номер рецепта;

Dom(pfid) = {0<№ingr1000}, где № ingr – номер ингредиента;

Dom(number) = { K| char(K)}, где char(K) — предикат, возвращающий значение «истина», если K — строка символов длинной не более 255, где K – количество данного продукта;

3) Отношение food (id, title, type);

Dom(id) = {0<№ingr1000}, где № ingr – номер ингредиента;

Dom(title) = { Npr| char(Npr)}, где char(Npr) — предикат, возвращающий значение «истина», если Npr — строка символов длинной не более 100, где Npr – название продукта;

Dom(type) = {0 Tp 1000}, где Tp – идентификатор постов;

4) Отношение holidays (id, title, description, kind);

Dom(id) = {0<№pr10000}, где № pr – номер по порядку;

Dom(title) = { Nps| char(Nps)}, где char(Nps) — предикат, возвращающий значение «истина», если Nps — строка символов длинной не более 100, где Nps – определитель введенного дня;

Dom(description) = { Nps| char(Nps)}, где char(Nps) — предикат, возвращающий значение «истина», если Nps — строка символов длинной не более 100, где Nps – расшифровка определителя;

Dom(kind) = {0<Vp10000}, где Vp – вид введенного дня;

Описание запросов в реляционной алгебре:

1. Вывести список рецептов для Многодневного Поста.

R1 = holidays Where (kind =2);

R2 = cookbook [id, title, howto, kind, type];

R3 = R1 Join R2.

2. Вывести список рецептов для Однодневного Поста.

R1 = holidays Where (kind =1);

R2 = cookbook [id, title, howto, kind, type];

R3 = R1 Join R2.

3. Вывести список рецептов для Сплошных Седьмиц.

R1 = holidays Where (kind =3);

R2 = cookbook [id, title, howto, kind, type];

R3 = R1 Join R2.

4. Вывести список рецептов для обычного дня.

R1 = holidays Where (kind =0);

R2 = cookbook [id, title, howto, kind, type];

R3 = R1 Join R2.

5. Вывести список рецептов, имеющих a, b, c ингредиенты.

a, b, c – определенные ингредиенты, имеющиеся у пользователя;

R1 = food Where (title = а Аnd title = b Аnd title = c);

R2 = cookbook_food [id, cbit, pfid, number];

R3 = R1 Join R2;

R4 = cookbook [id, title, howto, kind, type];

R5 = R3 Join R4.

6. Вывести список рецептов супов.

R1 = (cookbook [id, title, howto, kind, type]) Join (cookbook_food [id, cbit, pfid, number]);

R2 = cookbook Where (title = Суп);

R3 = (cookbook_food [id, cbit, pfid, number]) Join (food [id, title, type]);

R4 = R1 Join R2;

R5 = R4 Join R3;

3.3.8 Проектирование реляционной модели на основе концептуальной

Основное требование: каждый не ключевой атрибут должен встречаться только в одном отношении.

Реализация бинарной связи 1 : М

В этом случае для каждой сущности создается отдельное отношение. Ключ сущности с необязательной связью добавляется в другое отношение в качестве внешнего ключа.

К таким сущностям относятся:

• cookbook (id, title, howto, kind, type);

holidays (id, title, description, kind);

• cookbook (id, title, howto, kind, type);

cookbook_food (id, cbit, pfid, number);

• food (id, title, type);

cookbook_food (id, cbit, pfid, number);

• holidays (id, title, description, kind);

3.4 Физический уровень проектирования

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

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

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

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

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

3.4.1 Переход от реляционной модели к физической

Каждому отношению ставиться в соотношение таблица. Имя таблицы может совпадать с именем отношения, если оно не противоречит требованиям СУБД. Каждому атрибуту ставится в соответствие поле таблицы. В данном случае нет никакого противоречия и именам таблиц будут присвоены имена отношений, а каждому полю таблицы ставится атрибут.

3.4.2 Оформление запросов на языке SQL

1. Вывести список продуктов:

Select food.id,food.title From food Where food.id=’+ADOQuery1.FieldList.Fieldbyname(‘pfid’). asstring+

2. Вывести необходимый рецепт

Select cookbook_food.cbid,cookbook_food.pfid,cookbook_food.number From cookbook_food Where cookbook_food.cbid=’+inttostr(a)+

3. Вывести номер, название и способ приготовления рецептов

Select cookbook.id,cookbook.title,cookbook.howto From cookbook

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

Select cookbook_food.cbid,cookbook_food.pfid,cookbook_food.number From cookbook_food Where cookbook_food.cbid=’+inttostr(a)+

5. Список компонентов из таблицы food

Select food.id,food.title From food Where food.id=’+ADOQuery1.FieldList.Fieldbyname(‘pfid’). asstring+

6. Вывести из таблицы cookbook.type определенного типа, из таблицы cookbook вывести номер рецепта, соответствующий номеру рецепта в таблице_ cookbook , из таблицы food вывести номер ингредиента, соответствующего номеру ингредиента в таблице cookbook_food и из таблицы food название соответствующего ингредиента

.Select * From cookbook,cookbook_food,food Where ‘+ ‘(cookbook.type=»‘+ types_of_food[b,1]+'»)AND(cookbook_food.cbid=cookbook.id)AND(food.id=cookbook_food.pfid)AND(food.title=»‘+listbox2.Items.Strings[o]+

3.5 IDEF0-схема

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

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

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

• обеспечивает точное и лаконичное описание моделируемых объектов, удобство использования и интерпретации этого описания;
• облегчает взаимодействие и взаимопонимание системных аналитиков, разработчиков и персонала изучаемого объекта (фирмы, предприятия), т.е. служит средством «информационного общения» большого числа специалистов и рабочих групп, занятых в одном проекте, в процессе обсуждения, рецензирования, критики и утверждения результатов;
• позволяет визуализировать работу сложных систем, в том числе критически важных и требующих особой осторожности и соблюдения специальных мер безопасности;
• позволяет лаконично, однозначно и точно показать все элементы (блоки) системы и все отношения и связи между ними, выявить ошибочные, лишние или дублирующие связи и т.д.;
• позволяет составлять документацию, описывающую систему, и обмениваться информацией о таких системах. Язык не использует многословные характеристики, изложенные в форме традиционных текстов;
• прошел многолетнюю проверку и продемонстрировал работоспособность, как в проектах ВВС США, так и в других проектах, выполнявшихся государственными и частными промышленными компаниями;
• легок и прост в изучении и освоении;
• может генерироваться рядом инструментальных средств машинной графики.

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

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

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

---

Страница:   1   2   3   4

---