Разработка базы данных учета продажи товаров через Интернет магазин на примере сети магазинов «Меломан»

Общая структура системы

Данный проект, является гипертекстовым документом на основе содержимого БД. Доступ к БД осуществляется специальной CGI-программой, запускаемой WWW-сервером в ответ на запрос WWW — клиента. Эта программа, обрабатывая запрос, просматривает содержимое БД и создает выходной HTML-документ, возвращаемый клиенту.

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

Для реализации такой технологии используется взаимодействие WWW-сервера с запускаемой программой PHP.

На рисунке 7 представлена структура проекта.

Рисунок.7- Структура проекта.

Выбор программного инструментария

Язык базы данных SQL

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

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

До появления SQL в СУБД (независимо от того, на какой модели они основывались) приходилось поддерживать по крайней мере три языка, которые обычно имели мало общего: язык определения данных (ЯОД), служащий для спецификации структур БД (обычно общую структуру БД называют схемой БД); язык манипулирования данными (ЯМД), позволяющий создавать прикладные программы, взаимодействующие с БД; и язык администрирования БД (ЯАБД), с помощью которого можно было выполнять служебные действия (например, изменять структуру БД или производить ее настройку с целью повышения эффективности). Кроме того, если требовалось предоставить пользователям СУБД интерактивный доступ к БД, приходилось вводить еще один язык, операторы которого выполняются в диалоговом режиме. Язык SQL позволяет решать все эти задачи.

Следует отметить, что к достоинствам языка SQL относится наличие международных стандартов. Первый международный стандарт был принят в 1989 г., и соответствующая версия языка называется SQL-89. Этот стандарт поддерживается практически во всех современных коммерческих реляционных СУБД (например, в Informix, Sybase, Ingres и т. д.). Второй международный стандарт был принят в 1992 г. — SQL-92. Этот вариант языка существенно шире, чем SQL-89. К настоящему времени основные компании-производители СУБД только частично поддерживают этот стандарт. Тем не менее, он является исключительно важным документом как для реально практикующих разработчиков программного обеспечения, так и для специалистов, связанных с подбором аппаратно-программных средств.

История наиболее распространенного в настоящее время языка реляционных баз данных SQL насчитывает уже более 25 лет. Первый, достаточно полный функционально, но не полностью синтаксически и семантически определенный вариант языка SQL (его исходным названием было SEQUEL — StructuredEnglishQueryLanguage) был разработан и частично реализован в рамках проекта экспериментальной реляционной СУБД SystemR (проект выполнялся с 1974 по 1979 гг. в научно-исследовательской лаборатории компании IBM в г. Сан-Хосе, Калифорния).

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

• 1. средства определения схемы БД и манипулирования схемой;
• 2. операторы для определения ограничений целостности и триггеров;
• 3. средства определения представлений БД;
• 4. средства авторизации доступа к отношениям и их полям;
• 5. средства управления транзакциями.

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

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

Но на самом деле то же относится и к разным реализациям языков программирования (сравните, например, реализационные диалекты языка Си компиляторов Borland и GCC). Важно другое. Существует международный стандарт языка Си (ANSI/ISOC), который должен поддерживаться в любом компиляторе, претендующем на совместимость со стандартом (хотя реализационный диалект языка может содержать существенные расширения). Именно наличие стандарта языка Си в совокупности с другими стандартами Открытых Систем обеспечивает возможность создания легко переносимых прикладных (и иногда и системных) программ.

После появления в 1989 г. первого международного стандарта языка SQL (SQL-89) и, в особенности, после принятия в 1992 г. второго международного стандарта SQL-92 стало возможным говорить про стандартную среду SQL-ориентированной СУБД. Для грамотного использования любой SQL-ориентированной реляционной СУБД знание стандартов языка кажется необходимым.

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

Непроцедурный язык SQL (Structured Query Language — структуризованный язык запросов) ориентирован на операции с данными, представленными в виде логически взаимосвязанных совокупностей таблиц. Особенность предложений этого языка состоит в том, что они ориентированы в большей степени на конечный результат обработки данных, чем на процедуру этой обработки. SQL сам определяет, где находятся данные, какие индексы и даже наиболее эффективные последовательности операций следует использовать для их получения: не надо указывать эти детали в запросе к базе данных.

Появление теории реляционных баз данных и предложенного Коддом языка запросов «alpha», основанного на реляционном исчислении [2, 3], инициировало разработку ряда языков запросов, которые можно отнести к двум классам:

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

Разработка, в основном, шла в отделениях фирмы IBM (языки ISBL, SQL, QBE) и университетах США (PIQUE, QUEL) [3]. Последний создавался для СУБД INGRES (Interactive Graphics and Retrieval System), которая была разработана в начале 70-х годов в Университете шт. Калифорния и сегодня входит в пятерку лучших профессиональных СУБД. Сегодня из всех этих языков полностью сохранились и развиваются QBE (Query-By-Example — запрос по образцу) и SQL, а из остальных взяты в расширение внутренних языков СУБД только наиболее интересные конструкции.

В начале 80-х годов SQL показал все свой достоинства над другими языками запросов и стал фактическим стандартом таких языков для профессиональных реляционных СУБД. В 1987 году он стал международным стандартом языка баз данных и начал внедряться во все распространенные СУБД персональных компьютеров. Это произошло, потому что, непрерывный рост быстродействия, а также снижение энергопотребления, размеров и стоимости компьютеров привели к резкому расширению возможных рынков их сбыта, круга пользователей, разнообразия типов и цен. Естественно, что расширился спрос на разнообразное программное обеспечение. Борясь за покупателя, фирмы, производящие программное обеспечение, стали выпускать на рынок все более и более интеллектуальные и, следовательно, объемные программные комплексы. Приобретая такие комплексы, многие организации и отдельные пользователи часто не могли разместить их на собственных ЭВМ, однако не хотели, и отказываться от нового сервиса. Для обмена информацией и ее обобществления были созданы сети ЭВМ, где обобществляемые программы и данные стали размещать на специальных обслуживающих устройствах — файловых серверах [3].

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

Для исключения указанных и некоторых других недостатков была предложена технология «Клиент-Сервер», по которой запросы пользовательских ЭВМ (Клиент) обрабатываются на специальных серверах баз данных (Сервер), а на ЭВМ возвращаются лишь результаты обработки запроса. При этом, естественно, нужен единый язык общения с Сервером и в качестве такого языка выбран SQL. Поэтому все современные версии профессиональных реляционных СУБД (DB2, Oracle, Ingres, Informix, Sybase, Progress, Rdb) и даже нереляционных СУБД (например, Adabas) используют технологию «Клиент-Сервер» и язык SQL. К тому же приходят разработчики СУБД персональных ЭВМ, многие из которых уже сегодня снабжены языком SQL.

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

SQL обычно описывается как стандартный язык, используемый для взаимодействия с реляционными базами данных. Однако SQL не является языком программирования, как С, C++ или РНР. Скорее, это интерфейсное средство для выполнения различных операций с базами данных, предоставляющее в распоряжение пользователя стандартный набор команд. Возможности SQL не ограничиваются выборкой данных из базы. В SQL поддерживаются разнообразные возможности для взаимодействия с базой данных, в том числе [3]:

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

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

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

Наиболее близкими к SystemR являлись две системы фирмы IBM — SQL/DS и DB2. Как кажется (документальных подтверждений этому автор не имеет), обе эти системы прямо использовали реализацию SystemR. Отсюда предельная близость реализованных диалектов SQL к SQLSystemR. Из SQLSystemR были удалены только те части, которые были недостаточно проработаны (например, точки сохранения) или реализация которых вызывала слишком большие технические трудности (например, ограничения целостности и триггеры). Можно назвать этот путь к коммерческой реализации SQL движением сверху вниз.

Другой подход применялся в таких системах, как Oracle и Informix. Несмотря на различие в способе разработки этих систем, реализация SQL происходила «снизу вверх». В первых выпущенных на рынок реализациях SQL в этих системах использовалось минимальное и очень ограниченное подмножество SQLSystemR. В частности, в первой известной автору реализации SQL в СУБД Oracle в операторах выборки не допускалось использование вложенных подзапросов.

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

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