Краткий обзор различных субд
Методические указания по выполнению лабораторной работы №2
СУБД MySQL
Работа со структурой БД и
манипулирование данными
Оглавление
Введение. 2
1. Краткий обзор различных СУБД.. 3
3. Проектирование БД.. 7
3.1 Общие сведения о SQL. 8
3.2 Сведения об операторах SQL. 10
3.3 Сведения о типах данных. 10
4. Методические указания по выполнению практической части лабораторной работы на тему «Разработка базы данных в СУБД MySQL». 13
4.1 На что следует обратить внимание перед началом работы.. 14
4.2 Начало работы с MySQL. 14
4.3 Рассмотрим создание БД на примере БД для Интернет-продаж.. 14
4.3.1 Создадим новую БД.. 15
4.3.2 Создадим таблицу «Интернет-Магазины». 15
4.3.3 Создадим таблицу «Товары». 16
4.3.4 Создадим таблицу «Клиенты». 17
4.3.5 Создадим таблицу «Доставка». 19
4.3.6 Заполним таблицу «Интернет-Магазины». 20
4.3.7 Заполним таблицу «Товары». 20
4.3.8 Заполним таблицу «Клиенты». 21
4.3.9 Заполним таблицу «Заказы». 23
4.3.10 Заполним таблицу «Доставка». 24
4.3.11 Отобразим графически структуру созданной таблицы с помощью программного средства MySQL Workbench. 25
5. Варианты заданий для лабораторной работы на тему «Разработка базы данных в СУБД MySQL» 28
Список литературы.. 31
Введение
Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего, необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.
Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных. В случае реляционной модели данных под этим подразумевается следующее:
· создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
· определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;
· разработка средств защиты создаваемой системы.
Именно этому этапу и посвящена разрабатываемая ЛР.
Краткий обзор различных СУБД
Система управления базами данных (СУБД) - совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.
СУБД также имеют различные классификации, например, по модели данных:
· Иерархические
· Сетевые
· Реляционные
· Объектно-ориентированные
По степени распределенности:
· Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)
· Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах)
Подробнее рассмотрим классификацию по способу доступа к БД:
· Файл-серверные
В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на ЦП сервера. Недостатки: потенциально высокая загрузка локальной сети; затруднённость централизованного управления; затруднённость обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД.
На данный момент файл-серверная технология считается устаревшей.
Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.
· Клиент-серверные
Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность.
Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.
· Встраиваемые
Встраиваемая СУБД — СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL[1] либо через специальные программные интерфейсы.
Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР.
Наибольшее распространение получили, как можно сделать вывод из краткого описания, клиент-северные СУБД. Потому как в большинстве случаев клиент-серверная СУБД гораздо менее требовательна к пропускной способности компьютерной сети, чем файл-серверная СУБД, особенно при выполнении операции поиска в базе данных по заданным пользователем параметрам, т.к. для поиска нет необходимости получать на клиент весь массив данных: клиент передаёт параметры запроса серверу, а сервер производит поиск по полученному запросу в локальной базе данных. Результат выполнения запроса, который обычно на несколько порядков меньше по объёму, чем весь массив данных, возвращается клиенту, который обеспечивает отображение результата пользователю.
Далее в основном будем вести разговор именно о реляционных БД и файл-серверных СУБД.
Существует множество SQL-серверов[2] для управления реляционными базами данных. Каждый из них обладает своими достоинствами и недостатками. Рассмотрим некоторые из них:
Таблица 1 – Сравнение SQL-серверов
| Сервер | Достоинства | Недостатки |
| IBM DB2 Universal Database | Ниболее развитый язык запросов, лучший оптимизатор, возможность писать функции на других языках. | Высокая стоимость. |
| Oracle Database | Великое множество дополнительных возможностей. Версионный сервер. | Очень высокая стоимость сервера и поддержки. |
| Microsoft SQL Server | Быстро развивающийся продукт, уже вплотную приближающийся к своим более развитым конкурентам. Средняя стоимость. | Существует только для одной платформы (Win32). |
| Borland InterBase | Приличный набор возможностей. Версионный сервер. Бесплатный. | Относительно медленно работает. |
| PostgreSQL | Поддерживает историческую модель. Возможность создавать свои типы данных. Бесплатный. | Медленная работа некоторых команд. |
| MySQL | В настоящее время самый распространенный сервер. Очень быстро работает на простых запросах. Бесплатный. | Мало дополнительных возможностей. |
В таблице приведены лишь основные относительные плюсы и минусы разных СУБД. В действительности же имеется целых ряд отличий и к выбору СУБД следует подходить, в первую очередь, исходя из требований к конкретной базе данных и экономической целесообразности.
В данных методических указаниях рассматривается создание базы данных на примере MySQL-сервера, как наиболее простого, понятного и доступного из вышеперечисленных.
Проектирование БД
Создание БД на этапе физического проектирования может происходить несколькими способами. Выделим два фундаментальных способа создания БД:
· С помощью командной строки.
· С помощью специальных инструментов визуального проектирования БД.
В разработанной ЛР создание и наполнение БД предлагается выполнить с помощью командной строки. Это менее удобный и реже используемый способ, но он позволяет увидеть процесс моделирования БД «изнутри», более полно понять назначение операторов языка SQL, без знания которых проектирование с помощью специальных инструментов может быть затруднительным.
В процессе выполнения работы, будут подробно рассмотрены следующие операторы:
o CREATE
o DESC
o INSERT
o ALTER
o UPDATE
o DELETE
И использованы следующие типы данных:
o Числовые типы данных
o Типы данных даты и времени
o Символьные типы данных
Для создания структуры простой БД в рамках лабораторной работы необходимо пройти три упрощенных ключевых этапа:
· Определение сущностей БД
· Определение взаимосвязей между сущностями
· Нормализация БД
На четвертом и пятом листах показаны структуры БД, разрабатываемых в лабораторной работе, выполненные в приложение MySQL Workbench.
Общие сведения о SQL
Фактически стандартным языком доступа к базам данных в настоящее время стал язык SQL (Structured Query Language).
Данная лабораторная работа посвящена использованию языка SQL(Structured Query Language) для работы с базами данных в СУБД MySQL.
Текущая версия стандарта языка SQL принята в 1992 г. (Официальное название стандарта - Международный стандарт языка баз данных SQL (1992) (International Standart Database Language SQL), неофициальное название - SQL/92, или SQL-92, или SQL2). Документ, описывающий стандарт, содержит более 600 страниц. Здесь описывается только основная часть операторов языка.
Язык SQL стал фактически стандартным языком доступа к базам данных. Все СУБД, претендующие на название "реляционные", реализуют тот или иной диалект SQL. Многие нереляционные системы также имеют в настоящее время средства доступа к реляционным данным. Целью стандартизации является переносимость приложений между различными СУБД.
Нужно заметить, что в настоящее время, ни одна система не реализует стандарт SQL в полном объеме. Кроме того, во всех диалектах языка имеются возможности, не являющиеся стандартными. Таким образом, можно сказать, что каждый диалект - это надмножество некоторого подмножества стандарта SQL. Это затрудняет переносимость приложений, разработанных для одних СУБД в другие СУБД.
Язык SQL оперирует терминами, несколько отличающимися от терминов реляционной теории, например, вместо "отношений" используются "таблицы", вместо "кортежей" - "строки", вместо "атрибутов" - "колонки" или "столбцы".
Стандарт языка SQL, хотя и основан на реляционной теории, но во многих местах отходит он нее. Например, отношение в реляционной модели данных не допускает наличия одинаковых кортежей, а таблицы в терминологии SQL могут иметь одинаковые строки. Имеются и другие отличия.
Язык SQL является реляционно полным. Это означает, что любой оператор реляционной алгебры может быть выражен подходящим оператором SQL.
SQL является, прежде всего, информационно-логическим языком, предназначенным для описания, изменения и извлечения данных, хранимых в реляционных базах данных. SQL нельзя назвать языком программирования.
Основу языка SQL составляют операторы, условно разбитые не несколько групп по выполняемым функциям:
· Операторы DDL (Data Definition Language) - операторы определения объектов базы данных.
· Операторы DML (Data Manipulation Language) - операторы манипулирования данными.
· Операторы защиты и управления данными, и др.
Каждое предложение SQL — это запрос или обращение к базе данных, которое приводит к изменению в базе данных. В соответствии с тем, какие изменения происходят в базе данных, различают следующие типы запросов:
· запросы на создание или изменение в базе данных новых или существующих объектов (при этом в запросе описывается тип и структура создаваемого или изменяемого объекта);
· запросы на получение данных;
· запросы на добавление новых данных (записей)
· запросы на удаление данных;
· обращения к СУБД.
Основным объектом хранения реляционной базы данных является таблица, поэтому все SQL-запросы — это операции над таблицами. В соответствии с этим, запросы делятся на:
· запросы, оперирующие самими таблицами (создание и изменение таблиц);
· запросы, оперирующие с отдельными записями (или строками таблиц) или наборами записей.