Методы и средства проектирования информационных систем. Технология AMP: учебное пособие для студентов направлений 09.03.02, 09.04.02 «Информационные системы и технологии»

76 Pages·2014·0.658 MB·Russian

by  Васильев Н.П., Пресняков В.А., Гоголевский А.С.

Министерство образования и науки РФ

Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ЛЕСОТЕХНИЧЕСКИЙ
УНИВЕРСИТЕТ имени С. М. Кирова»

Кафедра информационных систем и технологий

Н. П. Васильев, кандидат технических наук, доцент
В. А. Пресняков, кандидат физико-математических наук, доцент
А. С. Гоголевский, кандидат технических наук

МЕТОДЫ И СРЕДСТВА
ПРОЕКТИРОВАНИЯ
ИНФОРМАЦИОННЫХ СИСТЕМ

ТЕХНОЛОГИЯ  AMP 

Учебное пособие
для студентов направлений 09.03.02, 09.04.02
«Информационные системы и технологии»

Санкт-Петербург
2014
Рассмотрено и рекомендовано к изданию
Научно-методическим советом
Санкт-Петербургского государственного лесотехнического университета
20 ноября 2014 г.

Отв. редактор
кандидат технических наук, профессор А. М. Заяц

Рецензенты:
кафедра информационных систем и вычислительной техники
Национального минерально-сырьевого университета «Горный»
(доктор технических наук, профессор И. В. Иванова),
профессор кафедры ВТ НИУИТМО,
доктор технических наук А. А. Ожиганов

УДК 004.62

Васильев, Н. П.
Методы и средства проектирования информационных систем. Техно-
логия AMP: учебное пособие для студентов направлений 09.03.02,
09.04.02 «Информационные системы и технологии» / Н. П. Васильев,
В. А. Пресняков, А. С. Гоголевский; под ред. А. М. Заяц. – СПб.:
СПбГЛТУ, 2014. – 76 с.
ISBN 978-5-9239-0718-6
Представлено кафедрой информационных систем и технологий.
В пособии рассмотрена широко используемая технология разработки
информационных систем на основе программных продуктов Apache,
MySQL и PHP, известная под аббревиатурой AMP. Рассмотрены теорети-
ческие основы проектирования реляционных баз данных.
Применение технологии подробно описывается на простом практиче-
ском примере. Даны необходимые для освоения примера начальные све-
дения о языке PHP и варианты доступа к данным в базе. Пособие содержит
задания для самостоятельного выполнения.

Темплан 2014 г. Изд. № 104.
ISBN 978-5-9239-0718-6 © СПбГЛТУ, 2014
2
ВВЕДЕНИЕ
Аббревиатура AMP означает: Apache, MySQL и PHP – программные про-
дукты, которые позволяют разрабатывать информационные системы от «а» до
«я» на основе клиент-серверных технологий.
Преимущества такого выбора:
– все указанные продукты являются свободно распространяемыми;
– можно использовать любую ОС - линейки Unix (в том числе и свободно
распространяемую систему Linux) или Windows и при этом разработка не будет
меняться;
– WEB интерфейс системы не требует установки клиентского программ-
ного обеспечения: для этого может использоваться любой WEB обозреватель;
– указанные продукты являются в настоящее время наиболее популярны-
ми и поддерживаются практически любыми хостерами во всемирной паутине.
В данном пособии приведены теоретические основы технологии AMP, а
практическая ее часть продемонстрирована на примере разработки простой ин-
формационной системы.
Центральной частью любой информационной системы является база дан-
ных. В настоящее время наибольшую популярность получили реляционные ба-
зы данных, которые фактически стали стандартом. Для управления реляцион-
ными базами ведущими фирмами разработаны программные продукты – серве-
ра баз данных. Сервер MySQL – из их числа. В основе любой реляционной ба-
зы лежит так называемая реляционная модель, поэтому в пособии, прежде все-
го, дается сжатое изложение основ этой модели, реляционной алгебры и реля-
ционного анализа данных. Далее излагаются основы языка PHP, приемы мани-
пулирования и доступа к данным с его помощью.

1. ВВЕДЕНИЕ В ПРОЕКТИРОВАНИЕ
РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

При проектировании базы данных решаются две основные проблемы:
• Каким образом представить предметную область в виде абстрактных
объектов модели данных, чтобы это представление не противоречило семанти-
ке предметной области и было, по возможности, лучшим (эффективным, удоб-
ным и т.д.)? Часто эту проблему называют проблемой логического проектиро-
вания баз данных.
• Как обеспечить эффективность выполнения запросов к базе данных, т. е.
каким образом, имея в виду особенности конкретной системы управления базами
данных (СУБД), расположить данные во внешней памяти, создания каких допол-
нительных структур (например, индексов) потребовать и т. д.? Эту проблему
обычно называют проблемой физического проектирования баз данных.
3
В случае реляционных баз данных трудно предложить какие-либо общие
рецепты по части физического проектирования. Здесь слишком многое зависит
от используемой СУБД. Поэтому ограничимся вопросами логического проек-
тирования реляционных баз данных, которые существенны при использовании
любой реляционной СУБД.
Более того, не будем касаться очень важного аспекта проектирования –
определения ограничений целостности общего вида (за исключением ограни-
чений, задаваемых функциональными зависимостями). Дело в том, что при ис-
пользовании СУБД с развитыми механизмами ограничений целостности (на-
пример, SQL-ориентированных систем) трудно предложить какой-либо уни-
версальный подход к определению ограничений целостности. Эти ограничения
могут иметь произвольно сложную форму, и их формулировка пока относится
скорее к области искусства, чем инженерного мастерства.
Проектирование реляционных баз данных трудно представить без введе-
ния так называемой реляционной модели данных и связанных с этой моделью
основных понятий (отношения, атрибутов, типов и доменов, кортежей, ключей
и т. д.). Представленный в данном разделе материал не претендует на полноту и
строгость изложения, тем не менее, может считаться своего рода введением в
теорию проектирования реляционных баз данных.

1.1. Реляционная модель
Понятие реляционной модели данных первым ввел основоположник реля-
ционного подхода Эдгар Кодд, а наиболее распространенная трактовка модели
принадлежит известному популяризатору идей Кодда - Кристоферу Дейту [1].
В своих работах К. Дейт развил теорию Кодда применительно к прикладным
задачам проектирования реляционных баз данных.
Согласно трактовке Дейта, реляционная модель состоит из трех частей, опи-
сывающих разные аспекты реляционного подхода:
1. Структурная часть;
2. Манипуляционная часть;
3. Целостная часть.
В структурной части модели фиксируется, что единственной родовой
структурой данных, используемой в реляционных БД, является нормализован-
ное n-арное отношение. Определяются понятия доменов, атрибутов, кортежей,
заголовка, тела и переменной отношения, которые обсуждается далее.
В манипуляционной части модели определяются две группы языков,
имеющие в качестве своей математической основы теоретические языки запро-
сов, предложенные Э.Коддом. Эти языки основаны на реляционной алгебре и
реляционном исчислении и эквивалентны друг другу по своим возможностям.
Существуют правила преобразования запросов между ними.
4
В целостной части реляционной модели данных фиксируются два базо-
вых требования целостности, которые должны поддерживаться в любой реля-
ционной СУБД. Это целостность сущности и ссылок.
1.1.1. Понятие отношения
Если не следовать точным определениям, то отношение (relation) можно
представить как обычную таблицу. То есть данные хранятся как последова-
тельность строк, а строки – последовательность клеток таблицы, содержащих
атомарные данные. При этом для отношения не важен порядок строк и порядок
столбцов, и эта особенность отличает отношение от обычной таблицы. Строки
таблицы часто называют записями или кортежами. Содержимое отношения
– это множество кортежей.
В таблице столбцы обычно имеют заголовки – имена. Применительно к
отношениям эти имена называются атрибутами отношения. Таким образом,
каждый кортеж отношения есть множество значений атрибутов, которые
также называют полями. Множество всех кортежей называют телом от-
ношения. Следует подчеркнуть, что множество не предполагает упорядоченно-
сти его элементов.
Значения атрибутов относятся к одному из заранее определенных типов.
Тип - это множество возможных значений, которые может принимать ат-
рибут. Например, это могут быть целые числа, дробные числа, строки, даты,
временные значения и т. д. Важно, чтобы эти значения были скалярными и не
допускали какую-либо дополнительную структуризацию. Понятие типа также
включает определение возможных операций, которые допустимы для значений
этого типа.
Часто к атрибутам предъявляют дополнительные требования. Суженное в
результате первоначальное множество значений заданного для атрибута ти-
па называют доменом, и атрибут тогда относят к этому домену. Строгое
определение домена предполагает введение некоторого логического выраже-
ния. Значение некоторого типа (на базе которого построен домен) можно отне-
сти к значениям домена, если результат вычисления этого выражения будет ис-
тинным.
Таким образом, для определения отношения, достаточно определить ат-
рибуты (их названия) и типы атрибутов или их домены. Имена атрибутов
должны быть уникальны. Определения атрибутов отношения, то есть уникаль-
ных имен атрибутов и их типов или доменов называют заголовком отношения
(или схемой отношения). Если определяются домены, то им должны быть даны
уникальные в рамках базы данных имена. Отношение содержит кортежи, кото-
рые для каждого атрибута содержат некоторое значение, относящееся к значе-
ниям заданного типа или домена. Самому отношению также дается подходящее
уникальное имя.
5
1.1.2. Понятие ключа
Тело любого отношения никогда не содержит кортежей – дубликатов. В
строгой теории это следует из определения тела отношения как множества кор-
тежей, поскольку в классической теории множеств по определению любое
множество состоит из различных элементов. Это свойство также является след-
ствием того, что каждый кортеж представляет некоторый реальный объект или
отражает ту или иную сторону реального мира. В теории баз данных принято
говорить в таких случаях о некоторых сущностях. Поскольку в реальном мире
все сущности различны (хотя бы по одному из свойств - атрибутов), то и кор-
тежи, их представляющие, должны отличаться.
На практике, часто, последний аргумент является слабым утешением, тем
не менее, уникальность кортежей – это одно из основных требований целостно-
сти, и в задачу проектировщика входит подбор атрибутов таким образом, чтобы
это требование соблюдалось. Если все кортежи отношения уникальны, то мож-
но выделить некоторое минимальное подмножество атрибутов, для которых
это требование уникальности сохраняется. То есть, если кортежи отношения
ограничить только этим набором атрибутов, то все они останутся различ-
ными. Этот минимальный набор атрибутов и называется ключом. Если ключ
содержит несколько атрибутов, то он называется составным.
Следует отметить, что на практике ключевое поле зачастую вводят ис-
кусственным образом. Кроме этого, иногда значения тех или иных полей оста-
ются неизвестными. В этих ситуациях в классической реляционной модели
вводят специальное неопределенное значение, которое обозначают через
NULL. Это значение применимо для атрибута любого типа. Однако для ключе-
вых полей неопределенное значение недопустимо, поскольку в противном слу-
чае, нарушается уникальность значений ключа.
Конечно, теоретически любой кортеж, заносимый в сохраняемое отноше-
ние, должен содержать все характеристики, моделируемой им сущности реаль-
ного мира, которые мы хотим сохранить в базе данных. Однако на практике не
все эти характеристики могут быть известны к тому моменту, когда требуется
зафиксировать сущность в базе данных. Простым примером может быть проце-
дура принятия на работу человека, размер заработной платы которого еще не
определен.
Если для отношения определен ключ (простой или составной), а значения
полей являются скалярными (можно сказать, атомарными), то говорят, что от-
ношение находится в состоянии первой нормальной формы.
1.1.3. Понятие внешнего ключа
Предположим, что требуется организовать в виде отношений данные о со-
трудниках некоторого предприятия, которые работают в разных отделах. Для
6
простоты изложения ограничимся кратким набором данных относительно самих
сотрудников, например, фамилией и табельным номером. Отделы предприятия
имеют номера и содержательные названия. Тогда фрагмент отношения с данными
о сотрудниках может иметь следующий вид, представленный в табл. 1.1.

Т а б л и ц а 1.1
Фрагмент отношения с данными
о сотрудниках некоторого предприятия

Табельный номер Имя Номер отдела Название отдела
num name dept_num dept_name
1 Петров 1 Отдел внешних
связей
2 Сидоров 1 Отдел внешних
связей
3 Иванов 2 Финансовый отдел
4 Фантиков 3 Отдел
планирования
5 Мавродий 2 Финансовый отдел
6 Голубков 2 Финансовый отдел
7 Плюшкин 4 Отдел рекламы

Ключевым полем данного отношения, очевидно, может служить поле та-
бельный номер - num. Каждому атрибуту дано уникальное имя, и каждый ат-
рибут имеет свой тип: номера – это целые числа, имена сотрудников и названия
отделов – строки. Таким образом, все формальные требования, предъявляемые
к отношению, соблюдены.
Однако в плане обеспечения целостности и исключения дублирования
данных, представленное отношение не терпит критики. Действительно, назва-
ния отделов в представленной таблице повторяются, и это плохо не только
сточки зрения расхода памяти. Предположим, что название какого-либо отдела
поменялось. Очевидно, в этом случае придется найти все строки с сотрудника-
ми из этого отдела и произвести их корректировку в поле dept_name. А что бу-
дет, если таких строк много и корректировка выполнена с ошибками? Ничего
хорошего – формально целостность данных будет нарушена.
Можно избежать подобных проблем, если выполнить декомпозицию и
хранить данные о сотрудниках в следующих двух отношениях, которые назо-
вем соответственно СОТРУДНИКИ (staff) и ОТДЕЛЫ (department) и предста-
вим в таблицах 1.2 и 1.3:

7
Т а б л и ц а 1.2
Отношение СОТРУДНИКИ (staff)
Табельный номер Имя Номер отдела
num name dept_num
1 Петров 1
2 Сидоров 1
3 Иванов 2
4 Фантиков 3
5 Мавродий 2
6 Голубков 2
7 Плюшкин 4

Т а б л и ц а 1.3
Отношение ОТДЕЛЫ (department)
Номер отдела Название отдела
dept_num dept_name
1 Отдел внешних связей
2 Финансовый отдел
3 Отдел планирования
4 Отдел рекламы

Во втором отношении department ключевым полем является поле
dept_num. Это поле также присутствует и в отношении staff, но здесь оно явля-
ется ссылкой, по которой можно найти развернутую информацию об отделе, в
котором работает сотрудник, в отношении department. Поля, подобные
dept_num в отношении staff, называются ссылочными или внешними ключами.
Понятно, что при обновлении ссылающегося отношения (вставке новых
кортежей или модификации значения внешнего ключа в существующих корте-
жах) достаточно следить за тем, чтобы не появлялись некорректные значения
внешнего ключа. Но как быть при удалении кортежа из отношения, на которое
ведет ссылка?
Здесь существуют три подхода, каждый из которых поддерживает цело-
стность по ссылкам.
Первый подход заключается в том, что вообще запрещается производить
удаление кортежа, для которого существуют ссылки (т. е. сначала нужно либо
удалить ссылающиеся кортежи, либо соответствующим образом изменить зна-
чения их внешнего ключа).
8
При втором подходе при удалении кортежа, на который имеются ссылки,
во всех ссылающихся кортежах значение внешнего ключа автоматически ста-
новится полностью неопределенным.
Наконец, третий подход (каскадное удаление) состоит в том, что при
удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося
отношения автоматически удаляются все ссылающиеся кортежи.
В развитых реляционных СУБД обычно можно выбрать способ поддер-
жания целостности по ссылкам для каждого случая определения внешнего
ключа. Конечно, для принятия такого решения необходимо анализировать тре-
бования конкретной прикладной области.
Для отображения ссылочных связей на схемах используется различная
символика, например, такая:
staff department

Рис 1.1. Изображение ссылочной связи один ко многим

Представленная на рис. 1.1 связь отношений является так называемой
связью один ко многим: каждый сотрудник может работать только в одном от-
деле, и в каждом отделе может работать несколько сотрудников. Только такие
связи допускаются реляционной моделью.
Здесь уместно заметить, что определение ключей, как первичных, так и вто-
ричных (то есть внешних), требует хорошего знания предметной области, кото-
рая моделируется в базе. Так, например, легко представить ситуацию, когда до-
пускается возможность работы сотрудника в нескольких отделах одновремен-
но. В этом случае требуются специальные приемы декомпозиции с привлече-
нием вспомогательного отношения, реализующего связь многие ко многим.
В настоящее время для отображения ссылочных связей отношений (Entity Rela-
tionship) разработаны специальные программные средства.
1.1.4. Реляционная алгебра
Основная идея реляционной алгебры состоит в том, что коль скоро отно-
шения являются множествами, средства манипулирования отношениями могут
базироваться на традиционных теоретико-множественных операциях, допол-
ненных некоторыми специальными операциями, специфичными для реляцион-
ных баз данных.
Существует много подходов к определению реляционной алгебры, кото-
рые различаются наборами операций и способами их интерпретации, но, в
принципе, являются более или менее равносильными. В данном разделе опи-
шем немного расширенный начальный вариант алгебры, который был предло-
9
жен Коддом (будем называть ее "алгеброй Кодда"). В этом варианте набор ос-
новных алгебраических операций состоит из восьми операций, которые делятся
на два класса – теоретико-множественные операции и специальные реляцион-
ные операции. В состав теоретико-множественных операций входят операции:
• объединения отношений;
• пересечения отношений;
• взятия разности отношений;
• взятия декартова произведения отношений.
Специальные реляционные операции включают:
• ограничение отношения;
• проекцию отношения;
• соединение отношений;
• деление отношений.
Кроме того, в состав алгебры включается операция присваивания, позво-
ляющая сохранить в базе данных результаты вычисления алгебраических вы-
ражений, и операция переименования атрибутов, дающая возможность кор-
ректно сформировать заголовок (схему) результирующего отношения.
Если не вдаваться в некоторые тонкости, то почти для всех операций
предложенного выше набора имеется очевидная и простая интерпретация.
При выполнении операции объединения (UNION) двух отношений с
одинаковыми заголовками производится отношение, включающее все кортежи,
которые входят хотя бы в одно из отношений-операндов.
Операция пересечения (INTERSECT) двух отношений с одинаковыми
заголовками производит отношение, включающее все кортежи, которые входят
в оба отношения-операнда.
Отношение, являющееся разностью (MINUS) двух отношений с одинако-
выми заголовками, включает все кортежи, входящие в отношение - первый
операнд, такие, что ни один из них не входит в отношение, которое является
вторым операндом.
При выполнении декартова произведения (TIMES) двух отношений, пе-
ресечение заголовков которых пусто, производится отношение, кортежи кото-
рого производятся путем объединения кортежей первого и второго операндов.
Результатом ограничения (WHERE) отношения по некоторому условию
является отношение, включающее кортежи отношения-операнда, удовлетво-
ряющее этому условию.
При выполнении проекции (PROJECT) отношения на заданное подмно-
жество множества его атрибутов производится отношение, кортежи которого
являются соответствующими подмножествами кортежей отношения-операнда.
При соединении (JOIN) двух отношений по некоторому условию образует-
ся результирующее отношение, кортежи которого производятся путем объедине-
ния кортежей первого и второго отношений и удовлетворяют этому условию.
10