Буханов С.А. (bukhanov@yandex.ru) Информационное обеспечение КИП(РТК)

Методические указания по выполнению лабораторной работы №2

СУБД MySQL

Работа со структурой БД и

манипулирование данными

Оглавление

Введение 2

1. Краткий обзор различных СУБД 3

3. Проектирование БД 7

3.1 Общие сведения о SQL 8

3.2 Сведения об операторах SQL 10

3.3 Сведения о типах данных 10

4. Методические указания по выполнению практической части лабораторной работы 13

4.1 На что следует обратить внимание перед началом работы 13

4.2 Начало работы с MySQL 14

4.3 Рассмотрим создание БД на примере БД для Интернет-продаж 14

4.3.1 Создадим новую БД 15

4.3.2 Создадим таблицу «Интернет-Магазины» 15

4.3.3 Создадим таблицу «Товары» 15

4.3.4 Создадим таблицу «Клиенты» 16

4.3.5 Создадим таблицу «Доставка» 18

4.3.6 Заполним таблицу «Интернет-Магазины» 20

4.3.7 Заполним таблицу «Товары» 20

4.3.8 Заполним таблицу «Клиенты» 21

4.3.9 Заполним таблицу «Заказы» 23

4.3.10 Заполним таблицу «Доставка» 23

4.3.11 Отобразим графически структуру созданной таблицы с помощью программного средства MySQL Workbench 24

5. Варианты заданий для лабораторной работы на тему «Разработка базы данных в СУБД MySQL» 28

Список литературы 31

Введение

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

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

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

• определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

• разработка средств защиты создаваемой системы.

Именно этому этапу и посвящена разрабатываемая ЛР.

1. Краткий обзор различных субд

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

СУБД также имеют различные классификации, например, по модели данных:

• Иерархические

• Сетевые

• Реляционные

• Объектно-ориентированные

По степени распределенности:

• Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

• Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах)

Подробнее рассмотрим классификацию по способу доступа к БД:

• Файл-серверные

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

На данный момент файл-серверная технология считается устаревшей.

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

• Клиент-серверные

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

Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.

• Встраиваемые

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

Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР.

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

Далее в основном будем вести разговор именно о реляционных БД и файл-серверных СУБД.

Существует множество SQL-серверов² для управления реляционными базами данных. Каждый из них обладает своими достоинствами и недостатками. Рассмотрим некоторые из них:

Таблица 1 – Сравнение SQL-серверов

Сервер	Достоинства	Недостатки
IBM DB2 Universal Database	Ниболее развитый язык запросов, лучший оптимизатор, возможность писать функции на других языках.	Высокая стоимость.
Oracle Database	Великое множество дополнительных возможностей. Версионный сервер.	Очень высокая стоимость сервера и поддержки.
Microsoft SQL Server	Быстро развивающийся продукт, уже вплотную приближающийся к своим более развитым конкурентам. Средняя стоимость.	Существует только для одной платформы (Win32).
Borland InterBase	Приличный набор возможностей. Версионный сервер. Бесплатный.	Относительно медленно работает.
PostgreSQL	Поддерживает историческую модель. Возможность создавать свои типы данных. Бесплатный.	Медленная работа некоторых команд.
MySQL	В настоящее время самый распространенный сервер. Очень быстро работает на простых запросах. Бесплатный.	Мало дополнительных возможностей.

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

В данных методических указаниях рассматривается создание базы данных на примере MySQL-сервера, как наиболее простого, понятного и доступного из вышеперечисленных.