компьютерный агент справочной службы

Глава 2. Проектная часть
2.1 Требования к программному обеспечению
2.2 Сведения о базах данных
2.2.1 Классификация баз данных
2.2.2. Структурные элементы базы данных
2.3 Виды моделей данных
2.4 Понятие информационного объекта
2.5 Нормализация отношений
2.5.1 Понятие нормализации отношений
2.6 Типы связей
2.7. Модели данных
2.7.1 Сведенья о моделях данных
2.7.2 Проектирование модели данных
2.7.3 Назначение модели
2.8 MySQL
2.9 PHP
Глава 3. Программная реализация компьютерного агента.

компьютерный агент справочной службы

все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
каждый столбец имеет уникальное имя;
одинаковые строки в таблице отсутствуют;
порядок следования строк и столбцов может быть произвольным.
Отношения представлены в виде таблиц, строки которых соответствуют записям, а столбцы — атрибутам отношений, полям.
Поле, каждое значение которого однозначно определяет соответствующую запись, на­зывается простым ключом (ключевым полем). Если записи однозначно определяются значениями нескольких полей, то такая таблица базы данных имеет составной ключ.
Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ — ключ второй таблицы.
Рис. 2.3 Пример реляционной модели
2.4 Понятие информационного объекта
Информационный объект — это описание некоторой сущности (реального объекта) в виде совокупности логически связанных реквизитов (информационных элементов).
Информационный объект имеет множество реализации — экземпляров, каждый из ко­торых представлен совокупностью конкретных значений реквизитов и идентифицируется значением ключа (простого — один реквизит или составного — несколько реквизитов). Ос­тальные реквизиты информационного объекта являются описательными. При этом одни и те же реквизиты в одних информационных объектах могут быть ключевыми, а в других - описательными. Информационный объект может иметь несколько ключей.
Классификация информационных объектов
Классификация по требуемой степени безотказности
От различных типов данных требуется различная степень безотказности доступа. Тратить большие деньги на системы безотказности для не очень важной информации невыгодно и даже убыточно, но нельзя и неправильно оценивать действительно постоянно требуемую информацию – ее отсутствие в неподходящий момент также может принести значительные убытки.
Классификация по уровню конфиденциальности
Классификация по степени конфиденциальности – одна из основных и наиболее старых классификаций данных. Она применялась еще задолго до появления вычислительной техники и с тех пор изменилась незначительно.
Требования по работе с конфиденциальной информацией
Различные классы конфиденциальной информации необходимо снабжать различными по уровню безопасности системами технических и административных мер.
2.5 Нормализация отношений
2.5.1 Понятие нормализации отношений
Одни и те же данные могут группироваться в таблицы (отношения) различными способами, т.е. возможна организация различных наборов отношений взаимосвязанных информацион­ных объектов.
Определенный набор отношений обладает лучшими свойствами при включении, мо­дификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений.
Нормализация отношений — позволяет устранить дублирова­ние, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Выделены три нормальные формы отношений:
Первая нормальная форма
Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нор­мальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.
Например, отношение Студент = (Номер, Фамилия, Имя, Отчество, Группа) на­водится в первой нормальной форме.
Вторая нормальная форма
Отношение будет находиться во второй нормальной форме, если оно находится в пер­вой нормальной форме, и каждый не ключевой атрибут функционально полно зависит от составного ключа.
Третья нормальная форма
Понятие третьей нормальной формы основывается на понятии нетранзитивной зави­симости.
Транзитивная зависимость наблюдается в том случае, если один из двух описательных реквизитов зависит от ключа, а другой описательный рекви­зит зависит от первого описательного реквизита.
Отношение будет находиться в третьей нормальной форме, если оно находится во вто­рой нормальной форме, и каждый неключевой атрибут нетранзитивно зависит от первично­го ключа.
Для устранения транзитивной зависимости описательных реквизитов необходимо про­вести «расщепление» исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов.
2.6 Типы связей
Все информационные объекты предметной области связаны между собой. Различаются связи нескольких типов, для которых введены следующие обозначения:
один к одному (1:1);
один ко многим (1 : М);
многие ко многим (М : М).
Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра инфор­мационного объекта В и наоборот.
При связи один ко многим (1:М) одному экземпляру информационного объекта А могут соответствовать два и более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с одним экземпляром объекта А.
Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А могут соответствовать два или более экземпляров объекта В и наоборот.
2.7 Модели данных
2.7.1 Сведенья о моделях данных2
Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель «сущность-связь» и т.д. Наиболее популярной из них оказалась модель «сущность-связь».
Сначала стали использовать иерархические даталогические модели но, если данные не имели древовидной структуры, то возникала масса сложностей при построении иерархической модели и желании добиться нужной производительности.
Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из «наборов» – поименованных двухуровневых деревьев. «Наборы» соединяются с помощью «записей-связок», образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество «маленьких хитростей», позволяющих увеличить производительность СУБД. Но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п.
Сложность практического использования иерархических и сетевых СУБД заставляла искать иные способы представления данных.
2.7.2 Проектирование модели данных
В теории проектирования информационных систем предметную область принято рассматривать в виде трех представлений:
представление предметной области в том виде, как она реально существует
как ее воспринимает человек (имеется в виду проектировщик базы данных)
как она может быть описана с помощью символов.
Т.е. говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.
Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC):
Внешнее представление (внешняя схема) данных является совокупностью требований к данным со стороны некоторой конкретной функции, выполняемой пользователем. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема - это сама база данных.
Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:
Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
обследование предметной области, изучение ее информационной структуры
выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами
моделирование и интеграция всех представлений
По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели «сущность-связь».
Логическое проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.
2.7.3 Назначение модели
Прежде, чем приступать к созданию системы автоматизированной обработки информации, разработчик должен сформировать понятия о предметах, фактах и событиях, которыми будет оперировать данная система. Для того, чтобы привести эти понятиях той или иной модели данных, необходимо заменить их информационными представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель «сущность-связь» (entity-relationship model, ER-model).
Модель «сущность-связь» основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Важным является тот факт, что из модели «сущность-связь» могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей.
Отметим, что модель «сущность-связь» не является моделью данных в строгом смысле, поскольку не определяет операций над данными и ограничивается описанием только их логической структуры.
2.8 MySQL3
MySQL — свободная система управления базами данных (СУБД). MySQL является собственностью компании MySQL AB, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL AB разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.
MySQL является решением для малых и средних приложений. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.
Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.
16 января 2008 года Sun Microsystems объявила о договоренности приобрести MySQL за $1 млрд, сделка должна завершится в 3-4 квартале 2008 финансового года.
О происхождении MySQL
MySQL возникла как попытка применить mSQL к собственным разработкам компании: таблицам, для которых использовались ISAM — подпрограммы низкого уровня. В результате был выработан новый SQL-интерфейс, но API-интерфейс остался в наследство от mSQL. Откуда происходит название «MySQL» — доподлинно не известно. Разработчики дают два варианта: либо потому, что практически все наработки компании начинались с префикса My, либо в честь девочки по имени My, дочери Майкла Монти Видениуса, одного из разработчиков системы.
Лицензирование
MySQL имеет двойное лицензирование. MySQL может распространяться в соответствии с условиями лицензии GPL. Но по условиям GPL, если какая-либо программа требует MySQL, то она тоже должна распространяться по лицензии GPL. Однако это может расходиться с планами разработчиков, не желающих открывать исходные текстов своих программ. Для таких случаев предусмотрена коммерческая лицензия компании MySQL AB, которая также обеспечивает качественную сервисную поддержку.
Платформы
MySQL портирована на большое количество платформ: AIX, BSDi, FreeBSD, HP-UX, GNU/Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, SGI IRIX, Solaris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP и прочим версиям Microsoft Windows. Существует также порт MySQL к OpenVMS. Важно отметить, что компания MySQL AB предоставляет для свободной загрузки не только исходные коды СУБД, но и откомпилированные и оптимизированные под конкретные операционные системы готовые исполняемые модули, которые можно загрузить с зеркал, представленных на официальном сайте.
Языки программирования
MySQL имеет API для языков C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk и Tcl, библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.
Устаревшая версия
Несмотря на то, что версия 4.0 является устаревшей, она широко распространена и её поддержка всё ещё осуществляется. Основные возможности этой версии:
- Практически полная реализация ANSI SQL-99, плюс расширения
- Межплатформенная совместимость
- Независимые механизмы хранения (MyISAM для быстрого чтения, InnoDB для транзакций и ссылочной целостности)
- Транзакции