Лекции.Орг
 

Категории:


Нейроглия (или проще глия, глиальные клетки): Структурная и функциональная единица нервной ткани и он состоит из тела...


Электрогитара Fender: Эти статьи описывают создание цельнокорпусной, частично-полой и полой электрогитар...


Агроценоз пшеничного поля: Рассмотрим агроценоз пшеничного поля. Его растительность составляют...

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



Методические указания по выполнению лабораторной работы №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-запросы — это операции над таблицами. В соответствии с этим, запросы делятся на:

· запросы, оперирующие самими таблицами (создание и изменение таблиц);

· запросы, оперирующие с отдельными записями (или строками таблиц) или наборами записей.

 





Дата добавления: 2016-11-23; просмотров: 1412 | Нарушение авторских прав


Рекомендуемый контект:


Похожая информация:

Поиск на сайте:


© 2015-2019 lektsii.org - Контакты - Последнее добавление

Ген: 0.006 с.