WWW.MASH.DOBROTA.BIZ
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - онлайн публикации
 

«САМОУЧИТЕЛЬ Санкт-Петербург «БХВ-Петербург» УДК 681.3.06 ББК 32.973.26-018.2 К89 Кузнецов М. В., Симдянов И. В. К89 Самоучитель MySQL 5. — СПб.: БХВ-Петербург, 2006. — 560 с.: ил. ISBN ...»

Максим Кузнецов

Игорь Симдянов

САМОУЧИТЕЛЬ

Санкт-Петербург

«БХВ-Петербург»

УДК 681.3.06

ББК 32.973.26-018.2

К89

Кузнецов М. В., Симдянов И. В .

К89 Самоучитель MySQL 5. — СПб.: БХВ-Петербург, 2006. — 560 с.: ил .

ISBN 978-5-94157-754-5

Описывается пятая версия популярной бесплатной СУБД MySQL. В начале книги происходит знакомство читателя с MySQL и простейшими

SQL-запросами, такими как создание баз данных и таблиц, их заполнение, извлечение и удаление записей. Далее рассматриваются сложные вопросы SQL-программирования: встроенные функции, полнотекстовый поиск, транзакции, временные таблицы. В заключительной части разбираются различные нововведения, появившиеся только в MySQL 5: вложенные запросы, хранимые процедуры и функции, представления, триггеры, курсоры, информационные схемы и т. п .

На компакт-диске размещена учебная база данных, на примере которой на протяжении всей книги демонстрируются особенности диалекта MySQL, и дистрибутивы MySQL версии 4.0, 4.1 и 5.0 для Windows и Linux, распространяемые в соответствии с лицензией GNU/GPL .

Для программистов и Web-разработчиков УДК 681.3.06 ББК 32.973.26-018.2

Группа подготовки издания:

Главный редактор Екатерина Кондукова Зам. главного редактора Евгений Рыбаков Зав. редакцией Григорий Добин Редактор Наталья Сержантова Компьютерная верстка Ольги Сергиенко Корректор Зинаида Дмитриева Дизайн серии Игоря Цырульникова Оформление обложки Елены Беляевой Зав. производством Николай Тверских Лицензия ИД № 02429 от 24.07.00. Подписано в печать 16.02.06 .



Формат 70 1001/16. Печать офсетная. Усл. печ. л. 45,15 .

Тираж 3000 экз. Заказ № "-Петербург", 194354, Санкт-Петербург, ул. Есенина, 5Б .

Санитарно-эпидемиологическое заключение на продукцию № 77.99.02.953.Д.006421.11.04 от 11.11.2004 г. выдано Федеральной службой по надзору в сфере защиты прав потребителей и благополучия человека .

Отпечатано с готовых диапозитивов

–  –  –

Введение

Для кого и о чем эта книга

Благодарности

ЧАСТЬ I.

Глава 1. История развития баз данных .

Понятие реляционной базы данных

1.1. История развития СУБД. Реляционные базы данных

1.1.1. Иерархические базы данных

1.1.2. Сетевые базы данных

1.1.3. Реляционные базы данных

1.1.4. Объектно-ориентированные и гибридные базы данных

1.2. Особенности реляционных баз данных

1.2.1. Первичные ключи

1.2.2. Нормализация базы данных

1.2.3. Правила Кодда

1.3. СУБД и сети

1.3.1. Централизованная архитектура

1.3.2. Архитектура "клиент-сервер"

1.3.2.1. Два признака клиент-серверной архитектуры

1.3.3. Трехуровневая архитектура Интернета

1.4. Как работают базы данных и что такое SQL

1.5. Версии MySQL

1.5.1. Что нового в MySQL 4.1

1.5.2. Что нового в MySQL 5.0

Глава 2. Установка MySQL 5

2.2. Установка на платформу Windows

2.3. Установка на платформу Linux

Глава 3. Работа с утилитами MySQL

Глава 4. Создание баз данных и таблиц .

Типы данных

4.1. Создание базы данных

4.2. Создание таблицы



4.3. Типы данных

4.3.1. Числовые данные

4.3.2. Строковые данные

4.3.3. Календарные данные

4.3.4. Тип данных NULL

4.3.5. Выбор типа данных

4.4. Учебная база данных

Глава 5. Индексы

Глава 6. Добавление данных

6.1. Однострочный оператор INSERT

6.2. Многострочный оператор INSERT

6.3. Пакетная загрузка данных

Глава 7. Выборка данных

7.1. Изменение количества и порядка следования столбцов

7.2. Условия

7.3. Сортировка

7.4. Ограничение выборки

7.5. Использование функций

7.6. Группировка записей

7.7. Объединение таблиц

7.8. Сохранение результатов во внешний файл

Глава 8. Удаление данных

Глава 9. Обновление данных

9.1. Оператор UPDATE

9.2. Оператор REPLACE

V Глава 10. Редактирование структуры таблиц

10.1. Добавление и удаление столбцов

10.2. Изменение уже существующих столбцов

10.3. Добавление и удаление индексов

10.4. Преобразование таблицы

ЧАСТЬ II

Глава 11. Типы и структура таблиц

11.1. MyISAM

11.2. MERGE

11.3. MEMORY (HEAP)

11.4. EXAMPLE

11.5. BDB (BerkeleyDB)

11.6. InnoDB

11.7. NDB Cluster

11.8. ARCHIVE

11.9. CSV

11.10. FEDERATED

11.11. Оператор CREATE TABLE

11.11.1. Структура таблицы

11.11.2. Параметры таблицы

ENGINE (TYPE)

AUTO_INCREMENT

AVG_ROW_LENGTH

[DEFAULT] CHARACTER SET

CHECKSUM

COMMENT

DATA DIRECTORY

DELAY_KEY_WRITE

INDEX DIRECTORY

INSERT_METHOD

MAX_ROWS

MIN_ROWS

PACK_KEYS

PASSWORD

ROW_FORMAT

UNION

11.12. Изменение типа таблицы

Глава 12. Приведение типов

12.1. Ключевое слово BINARY

12.2. Функция CAST

12.3. Функция CONVERT

VI Глава 13. Операторы и математические функции

13.1. Операторы

13.1.1. Арифметические операторы

13.1.2. Операторы сравнения

13.1.2.1. Равенство =

13.1.2.2. Оператор =

13.1.2.3. Оператор

13.1.2.4. Оператор

13.1.2.5. Оператор =

13.1.2.6. Оператор

13.1.2.7. Оператор =

13.1.2.8. Конструкция IS NULL

13.1.2.9. Конструкция IS NOT NULL

13.1.2.10. Конструкция BETWEEN min AND max

13.1.2.11. Конструкция NOT BETWEEN min AND max

13.1.2.12. Функция COALESCE

13.1.2.13. Функция GREATEST

13.1.2.14. Функция LEAST

13.1.2.15. Конструкция IN

13.1.2.16. Конструкция NOT IN

13.1.2.17. Функция INTERVAL





13.1.3. Логические операторы

13.1.3.1. Оператор NOT

13.1.3.2. Оператор OR

13.1.3.3. Оператор AND

13.1.3.4. Оператор XOR

13.1.4. Битовые операторы

13.1.4.1. Оператор &

13.1.4.2. Оператор |

13.1.4.3. Оператор ^

13.1.4.4. Оператор ~

13.1.4.5. Оператор

13.1.4.6. Оператор

13.1.4.7. Функция BIT_COUNT

13.1.5. Приоритет операторов

13.2. Математические функции

13.2.1. Функция ABS

13.2.2. Функция ACOS

13.2.3. Функция ASIN

13.2.4. Функция ATAN

13.2.5. Функция ATAN2

13.2.6. Функция CEILING

13.2.7. Функция COS

13.2.8. Функция COT

VII 13.2.9. Функция CRC32

13.2.10. Функция DEGREES

13.2.11. Функция EXP

13.2.12. Функция FLOOR

13.2.13. Функция LOG

13.2.14. Функция LOG2

13.2.15. Функция LOG10

13.2.16. Функция MOD

13.2.17. Функция PI

13.2.18. Функция POW

13.2.19. Функция RADIANS

13.2.20. Функция RAND

13.2.21. Функция ROUND

13.2.22. Функция SIGN

13.2.23. Функция SIN

13.2.24. Функция SQPT

13.2.25. Функция TAN

13.2.26. Функция TRUNCATE

Глава 14. Функции даты и времени

14.1. Функция ADDDATE

14.2. Функция ADDTIME

14.3. Функция CONVERT_TZ

14.4. Функция CURDATE

14.5. Функция CURTIME

14.6. Функция DATE

14.7. Функция DATEDIFF

14.8. Функция DATE_FORMAT

14.9. Функция DAY

14.10. Функция DAYNAME

14.11. Функция DAYOFMONTH

14.12. Функция DAYOFWEEK

14.13. Функция DAYOFYEAR

14.14. Функция EXTRACT

14.15. Функция FROM_DAYS

14.16. Функция FROM_UNIXTIME

14.17. Функция GET_FORMAT

14.18. Функция HOUR

14.19. Функция LAST_DAY

14.20. Функция MAKEDATE

14.21. Функция MAKETIME

14.22. Функция MICROSECOND

14.23. Функция MINUTE

14.24. Функция MONTH

VIII

14.25. Функция MONTHNAME

14.26. Функция NOW

14.27. Функция PERIOD_ADD

14.28. Функция PERIOD_DIFF

14.29. Функция QUARTER

14.30. Функция SECOND

14.31. Функция SEC_TO_TIME

14.32. Функция STR_TO_DATE

14.33. Функция SUBDATE

14.34. Функция SUBTIME

14.35. Функция TIME

14.36. Функция TIMEDIFF

14.37. Функция TIMESTAMP

14.38. Функция TIMESTAMPADD

14.39. Функция TIMESTAMPDIFF

14.40. Функция TIME_FORMAT

14.41. Функция TIME_TO_SEC

14.42. Функция TO_DAYS

14.43. Функция UNIX_TIMESTAMP

14.44. Функция UTC_DATE

14.45. Функция UTC_TIME

14.46. Функция UTC_TIMESTAMP

14.47. Функция WEEK

14.48. Функция WEEKDAY

14.49. Функция WEEKOFYEAR

14.50. Функция YEAR

14.51. Функция YEARWEEK

Глава 15. Строковые функции

15.1. Функция ASCII

15.2. Функция BIN

15.3. Функция BIT_LENGTH

15.4. Функция CHAR

15.5. Функция CHAR_LENGTH

15.6. Функция CHARSET

15.7. Функция COLLATION

15.8. Функция COMPRESS

15.9. Функция CONCAT

15.10. Функция CONCAT_WS

15.11. Функция CONV

15.12. Функция ELT

15.13. Функция EXPORT_SET

15.14. Функция FIELD

15.15. Функция FIND_IN_SET

IX

15.16. Функция FORMAT

15.17. Функция HEX

15.18. Функция INSERT

15.19. Функция INSTR

15.20. Функция LEFT

15.21. Функция LENGTH

15.22. Функция LOAD_FILE

15.23. Функция LOCATE

15.24. Функция LOWER

15.25. Функция LPAD

15.26. Функция LTRIM

15.27. Функция MAKE_SET

15.28. Функция MID

15.29. Функция OCT

15.30. Функция ORD

15.31. Функция POSITION

15.32. Функция QUOTE

15.33. Функция REPEAT

15.34. Функция REPLACE

15.35. Функция REVERSE

15.36. Функция RIGHT

15.37. Функция RDAP

15.38. Функция RTRIM

15.39. Функция SOUNDEX

15.40. Функция SPACE

15.41. Функция SUBSTRING

15.42. Функция SUBSTRING_INDEX

15.43. Функция TRIM

15.44. Функция UNCOMPRESS

15.45. Функция UNCOMPRESSED_LENGTH

15.46. Функция UNHEX

15.47. Функция UPPER

Глава 16. Безопасность и MySQL

16.1. Функции AES_ENCRYPT и AES_DECRYPT

16.2. Функции ENCODE и DECODE

16.3. Функции DES_ENCRYPT и DES_DECRYPT

16.4. Функция ENCRYPT

16.5. Функция MD5

16.6. Функция PASSWORD

16.7. Функция SHA1

Глава 17. Поиск и регулярные выражения

17.3. Оператор SOUND LIKE

17.4. Оператор RLIKE (REGEXP)

17.5. Оператор NOT RLIKE

17.6. Функция STRCMP

Глава 18. Полнотекстовый поиск

18.1. Индекс FULLTEXT

18.2. Конструкция MATCH (...) AGAINST (...)

18.3. Логический режим

Глава 19. Функции, применяемые вместе с конструкцией GROUP BY

19.1. Функция AVG()

19.2. Функция BIT_AND()

19.3. Функция BIT_OR()

19.4. Функция BIT_XOR()

19.5. Функция COUNT()

19.6. Функция GROUP_CONCAT()

19.7. Функция MIN()

19.8. Функция MAX()

19.9. Функция STD()

19.10. Функция STDDEV_SAMP()

19.11. Функция SUM()

19.12. Функция VAR_POP()

19.13. Функция VAR_SAMP()

19.14. Конструкция WITH ROLLUP

Глава 20. Разные функции

20.1. Функции управления потоком выполнения

20.1.1. Функция CASE

20.1.2. Функция IF()

20.1.3. Функция IFNULL()

20.1.4. Функция NULLIF()

20.2. Информационные функции

20.2.1. Функция BENCHMARK()

20.2.2. Функция CONNECTION_ID()

20.2.3. Функция CURRENT_USER()

20.2.4. Функция DATABASE()

20.2.5. Функция FOUND_ROWS()

20.2.6. Функция LAST_INSERT_ID()

20.2.7. Функция USER()

20.2.8. Функция VERSION()

20.3. Разные функции

20.3.1. Функция DEFAULT()

XI 20.3.2. Функция GET_LOCK()

20.3.3. Функция INET_ATON()

20.3.4. Функция INET_NTOA()

20.3.5. Функция IS_FREE_LOCK()

20.3.6. Функция IS_USED_LOCK()

20.3.7. Функция RELEASE_LOCK()

20.3.8. Функция UUID()

Глава 21. Переменные и временные таблицы

Глава 22. Многотабличные запросы

22.1. Перекрестное объединение таблиц

22.2. Объединение таблиц при помощи JOIN

22.3. Обновление нескольких таблиц

22.4. Удаление из нескольких таблиц

Глава 23. Вложенные запросы

23.1. Вложенный запрос как скалярный операнд

23.2. Вложенные запросы, возвращающие несколько строк

23.2.1. Ключевое слово IN

23.2.2. Ключевое слово ANY (SOME)

23.2.3. Ключевое слово ALL

23.3. Проверка на существование

23.4. Коррелированные запросы

23.5. Вложенные запросы, возвращающие несколько столбцов

23.6. Подзапросы в конструкции FROM

23.7. Вложенные запросы в операторе CREATE TABLE

23.8. Вложенные запросы в операторе INSERT

23.9. Ссылочная целостность

Глава 24. Транзакции и блокировки

Глава 25. Управление учетными записями пользователей

25.1. Учетные записи СУБД MySQL

25.2. Оператор CREATE USER

25.3. Оператор DROP USER

25.4. Оператор RENAME USER

25.5. Оператор GRANT

25.6. Оператор REVOKE

XII Глава 26. Предотвращение катастроф и восстановление

26.1. Оператор CHECK TABLE

26.2. Оператор ANALYZE TABLE

26.3. Оператор CHECKSUM TABLE

26.4. Оператор OPTIMIZE TABLE

26.5. Оператор REPAIR TABLE

26.6. Оператор BACKUP TABLE

26.7. Оператор RESTORE TABLE

Глава 27. Административные команды

ЧАСТЬ III

Глава 28. Хранимые процедуры

28.1. Хранимые процедуры и привилегии

28.2. Создание хранимой процедуры

28.2.1. Тело процедуры

28.2.2. Параметры процедуры

28.2.3. Работа с таблицами базы данных

28.2.4. Хранимые функции

28.3. Группа характеристик хранимых процедур

28.4. Операторы управления потоком данных

28.4.1. Оператор IF...THEN...ELSE

28.4.2. Оператор CASE

28.4.3. Оператор WHILE

28.4.4. Оператор REPEAT

28.4.5. Оператор LOOP

28.4.6. Оператор GOTO

28.5. Метаданные

28.5.1. Оператор SHOW PROCEDURE STATUS

28.5.2. Оператор SHOW CREATE

28.5.3. Извлечение информации из таблицы mysql.proc

28.6. Удаление хранимых процедур

28.7. Редактирование хранимых процедур

28.8. Обработчики ошибок

28.9. Курсоры

Глава 29. Триггеры

Глава 30. Представления

30.1. Создание представлений

30.2. Удаление представлений

XIII

30.3. Редактирование представлений

30.4. Оператор SHOW CREATE VIEW

Глава 31. Информационная схема

Заключение

Приложение. Описание компакт-диска

Предметный указатель

XIV Книга посвящена описанию СУБД MySQL и особенностям ее диалекта языка SQL .

Популярность реляционных баз данных неуклонно возрастает в последние десятилетия. СУБД MySQL представляет собой СУБД с открытым кодом, разработкой которой занимается корпорация MySQL AB. СУБД MySQL успешно работает под управлением свыше 20 различных операционных систем (Windows, Linux, OS/2, Mac OS X, FreeBSD, Solaris, SunOS, OpenBSD, NetBSD, AIX, DEC Unix, Tru64 Unix и т. д.), а также предоставляет интерфейс для взаимодействия с множеством языков программирования: C, C++, Eiffel, Java, Perl, PHP, Python, Ruby и Tcl .

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

На сегодняшний день MySQL, наряду с СУБД Oracle, является одной из самых быстрых баз данных. В версии MySQL 5.0 была достигнута функциональность, доступная ранее только в коммерческих базах данных. Так, введены долгожданные вложенные запросы, хранимые процедуры, курсоры, обработчики ошибок, триггеры, представления и множество новых внутренних функций .

Книга будет полезна как начинающим разработчикам приложений с применением баз данных, которые хотят разобраться во всех тонкостях работы с MySQL, так и профессионалам, использовавшим в своей работе более ранние версии MySQL (3 и 4) и желающим познакомиться с нововведениями MySQL 5 .

0. Изложение в книге ведется таким образом, чтобы у читателя, незнакомого с языком запросов SQL, материал книги не вызвал затруднений. На протяжении всей книги нововведения версий 4.1 и 5.0 указываются явно в замечании, поэтому книга может быть полезна разработчикам, использующим более старые версии СУБД MySQL, но планирующим со временем использовать новые версии .

2 Первая часть книги посвящена основам SQL и взаимодействию с сервером MySQL .

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

На протяжении всей книги используется учебная база данных электронного магазина, которую можно найти в каталоге base прилагаемого к книге компакт-диска, а также загрузить по адресу http://www.softtime.ru/sql/base.zip. Помимо этого, компакт-диск содержит дистрибутивы СУБД MySQL версий 4.0, 4.1 и 5.0 для операционных систем Windows и Linux. Кроме того, на прилагаемом компакт-диске вы сможете найти документацию на русском и английском языках и клиенты с графическим интерфейсом для обращения к серверу MySQL .

По всем вопросам, которые могут возникнуть по мере чтения материала книги, вы можете обращаться на форум, расположенный на Web-сайте IT-студии SoftTime, сотрудниками которой являются авторы книги (http://www.softtime.ru/forum /index.php?id_forum=3). Авторы присутствуют на форуме каждый день и в меру своей компетенции постараются ответить на ваши вопросы .

–  –  –

.

Компьютерные технологии постоянно эволюционируют. Это связано с тем, что программы, которые от них требуются, становятся все более и более изощренными, а чем сложнее программа, тем больше кода необходимо для ее создания. За время существования этой отрасли программисты сменили машинные коды на ассемблер, ассемблер на языки высокого уровня. Каждый новый виток в технологии программирования обеспечивал одну простую вещь — программист мог создавать более сложные программы, содержащие большее число строк. Когда мощности языков высокого уровня стало не хватать и программы достигли уровня десятков тысяч строк, появилось структурное программирование, позволившее увеличить объем программы до 100 000 строк. Очень скоро и данного предела оказалось недостаточно, и был предложен объектно-ориентированный подход, который позволил создавать еще более сложные и объемные программы .

Программы — это процессы, которые манипулируют данными. Как же происходила эволюция данных? В далеких 60-х годах прошлого столетия программисты использовали машинные коды и файлы. В настоящий момент ни прикладное, ни даже системное программное обеспечение в машинных кодах не пишется, однако файлы используются повсеместно. Значит ли это, что эволюции не было? Ответу на этот вопрос посвящена данная глава .

1.1. .

Задача длительного хранения и обработки информации появилась практически сразу с созданием первых компьютеров. Для решения этой задачи в конце 60-х годов XX века были разработаны специализированные программы, получившие название систем управления базами данных (СУБД). СУБД проделали длительный путь эволюции от системы управления файлами через иерархические и сетевые базы данных к реляционным моделям. В конце 80-х годов XX века доминирующей стала система управления реляционными базами данных (СУРБД). С этого времени такие СУБД 6 I стали стандартом де-факто. Каждая СУБД имела свой собственный язык запросов, и для того, чтобы унифицировать работу с ними, был разработан структурированный язык запросов SQL (Structured Query Language), который представляет собой язык управления реляционными базами данных. Цель данного раздела — рассмотреть реляционную модель данных, сравнив ее с более ранними СУБД: иерархическими и сетевыми .

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

Существуют следующие разновидности баз данных:

иерархические;

сетевые;

реляционные;

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

гибридные .

1.1.1 .

Первыми базами данных были иерархические. Иерархическая база данных основана на древовидной структуре хранения информации и в этом смысле напоминает файловую систему компьютера. Наиболее известным и распространенным примером иерархической базы данных является Information Management System (IMS) фирмы IBM, первая версия которой появилась в 1968 г. С точки зрения организации хранения информации иерархическая база данных состоит из упорядоченного набора деревьев одного типа, т. е. каждая запись в базе данных реализована виде отношений "предок-потомок". На рис. 1.1 показана схема организации такой иерархической базы данных .

Рис. 1.1. Схема организации иерархической базы данных на примере войсковой части 1.. 7

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

Реальная иерархическая база данных войсковой части может выглядеть, к примеру, так, как показано на рис. 1.2 .

Рис. 1.2. Иерархическая база данных



Основной недостаток иерархической структуры базы данных — невозможность реализовать отношения "многие-ко-многим", а также ситуации, когда запись имеет несколько предков .

Иерархические базы данных наиболее пригодны для моделирования структур, являющихся иерархическими по своей природе. Самым простым примером такой структуры является воинское подразделение, имеющее очевидную естественную иерархию. Однако существует очень много структур, которые невозможно свести к простой иерархии, и в этом случае применение иерархической базы данных становится невозможным. Примером такой структуры является всем известное генеалогическое древо, которое, казалось бы, как нельзя лучше подходит для описания его в терминах иерархической базы данных, однако это сделать невозможно, поскольку каждый потомок имеет двух родителей .

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

–  –  –

расширением иерархических. То есть если в иерархических базах данных структура "запись-потомок" должна иметь только одного предка, то в сетевой базе данных потомок может иметь любое количество предков .

Термин "сетевая" в данном случае не подразумевает никакого намека на локальные сети. Этим словом обозначается модель связей в базе данных, когда каждая запись может находиться в отношениях "многие-ко-многим" с другими записями, что делает графическую модель базы похожей на рыбацкую сеть (рис. 1.3) .

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

–  –  –

Основным недостатком сетевых баз данных является сложность разработки серьезных приложений .

1.1.3 .

Настоящий прорыв в развитии теории баз данных произошел тогда, когда возросшая мощность компьютеров позволила реализовать реляционную модель данных. Теория реляционных баз данных была разработана доктором Коддом из компании IBM в 1970 году. Одной из задач реляционной модели была попытка упростить структуру базы данных. В ней отсутствовали явные указатели на предков и потомков, а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых расположены данные .

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

Каждая база данных может включать несколько таблиц, которые, как правило, связаны друг с другом, откуда и произошло название "реляционные" .

Рис. 1.4. Таблица реляционной базы данных

На рис. 1.4 приведен пример таблицы catalog базы данных электронного магазина компьютерных комплектующих, которые распределены по разделам. Каждая строка этой таблицы представляет собой один вид товарных позиций, для описания которых используется поле id_catalog — уникальный номер раздела, name — название раздела и description — его описание .

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

Реляционной базой данных называется такая база данных, в которой все данные организованы в виде таблиц, а все операции над этими данными сводятся к операциям над таблицами .

–  –  –

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

1.2 .

Можно кратко сформулировать особенности реляционной базы данных .

Данные хранятся в таблицах, состоящих из столбцов и строк .

На пересечении каждого столбца и строки находится только одно значение .

У каждого столбца есть свое имя, которое служит его названием, и все значения в одном столбце имеют один тип. Например, в столбце id_products все значения имеют целочисленный тип, а в строке name — текстовый .

Столбцы располагаются в определенном порядке, который задается при создании таблицы, в отличие от строк, которые располагаются в произвольном порядке .

В таблице может не быть ни одной строчки, но обязательно должен быть хотя бы один столбец .

Запросы к базе данных возвращают результат в виде таблиц, которые тоже могут выступать как объект запросов .

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

Правила Кодда и их разъяснение приведены в конце данной главы. Они не являются догматическими — реляционные базы данных постоянно развиваются и совершенствуются, на рынке появляются новые продукты, которые поддерживают не все требования к реляционным базам данных. Например, MySQL долго не соответствовала многим стандартам SQL. Исторически сложилось так, что последним стандартам SQL не соответствует ни одна из баз данных .

1.2.1 .

Строки в реляционной базе данных неупорядочены. То есть в таблице нет "первой", "последней", "тридцать шестой" и "сорок третьей" строки, а есть просто неупорядоченный набор строк. Возникает вопрос: "Каким же образом выбирать в таблице конкретную строку?" Для этого в правильно спроектированной базе данных для каждой таблицы создается один или несколько столбцов, значения которых во всех строках различны. Такой столбец называется первичным ключом таблицы. Первичный ключ обычно сокращенно обозначают как PK (primary key). Никакие из двух записей таблицы не могут иметь одинаковых значений первичного ключа — т. е., благодаря наличию первичных ключей, каждая строка таблицы обладает своим уникальным идентификатором .

В математике таблица, все строки которой отличаются друг от друга, называется отношением, — по-английски relation. Именно этому английскому термину реляционные базы данных и обязаны своим названием .

По способу задания первичных ключей различают логические (естественные) ключи и суррогатные (искусственные) .

Для логического задания первичного ключа нужно выбрать в базе данных то, что естественным образом определяет запись. Примером такого ключа является номер паспорта в базе данных о паспортных данных жителей. К примеру, в таблице базы данных, содержащей паспортные данные, уникальный индекс можно создать для поля "номер паспорта", поскольку каждый такой номер является единственным в своем роде. А вот дата рождения уже не уникальна, поэтому индекс по полю "Дата рождения" не может быть уникальным .

Если подходящих примеров для естественного задания первичного ключа не находится, пользуются суррогатным ключом. Суррогатный ключ представляет собой дополнительное поле в базе данных, предназначенное для обеспечения записей первичным ключом. Таким ключом, к примеру, является столбец id_products, базы данных товаров компьютерного магазина (см. рис. 1.4) .

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

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

Например, рассмотрим базу данных какого-либо форума. В любом форуме обязательно присутствуют темы, в которых пользователи оставляют сообщения. Таким образом, в данном приближении мы имеем две таблицы: таблицу с названиями тем themes и таблицу posts с названиями сообщений. Еще раз обратим внимание на то, что строки в таблицах неупорядочены: т. е. у нас в таблице тем вперемешку содержатся строки с названиями тем, а в таблице сообщений — тексты сообщений. А как мы знаем, сообщения должны относиться к строго определенным темам. СледоваI тельно, встает задача установления взаимно однозначного соответствия между названиями тем и сообщениями в этих темах. Такое соответствие также устанавливается с помощью первичных ключей (рис. 1.5) .

–  –  –

Первичным ключом таблицы themes является id_theme, а таблицы posts — id_post .

Обратите внимание, что поле id_theme присутствует и в таблице posts. Каждое значение этого поля в таблице posts является внешним ключом (в данном случае это внешний ключ для первичного ключа таблицы themes). Внешний ключ сокращенно обозначают как FK (foreign key) .

Внешний ключ также часто называют вторичным ключом .

Как видно из рис. 1.5, внешний ключ ссылается на первичный ключ таблицы themes, устанавливая однозначную логическую связь между записями таблиц themes и posts .

Иначе говоря, если внешний ключ для записи (сообщения) с PK=1 в таблице posts имеет значение внешнего ключа равное 1, то это значит, что данное сообщение относится к теме с PK=1 таблицы themes .

1.2.2 .

Нормализацией схемы базы данных называется процедура, производимая над базой данных с целью удаления в ней избыточности .

Для того чтобы лучше уяснить приведенное определение нормализации, рассмотрим следующий пример. На рис. 1.6 показана таблица, в которой указаны фамилии сотрудников и их профессии .

1.. 13

–  –  –

Эта таблица избыточна — для каждого из сотрудников повторяются одинаковые названия профессий. То есть схема такой базы данных не нормализована. Для небольшой базы данных это не критично, но в больших по объему базах это скажется на размере базы и, в конечном счете, на скорости доступа. Для нормализации необходимо разбить эту таблицу на две — профессий и фамилий сотрудников, как это показано на рис. 1.7 .

<

Рис. 1.7. Нормализованная схема соответствия профессий и сотрудников

Теперь каждый тип профессии обозначен уникальным числом, и строка в базе данных присутствует только в единственном экземпляре: в таблице профессий. Размер поля "профессия" уменьшился, т. к. строка занимает больше памяти, чем число .

Очевидно, что нормализация несет в себе немало преимуществ: в нормализованной базе данных уменьшается вероятность возникновения ошибок, она занимает меньше места на жестком диске и т. д .

–  –  –

водит к обратному эффекту — замедлению работы базы данных. Поэтому иногда для упрощения запросов даже прибегают к обратной процедуре — денормализации .

1.2.3 .

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

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

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

3. Правило обработки отсутствующих значений. Должна быть реализована поддержка отсутствующих значений, которые не являются ни строками нулевой длины, ни строками пробельных символов, ни нулем или каким-либо другим числом, а используются для представления отсутствующих данных, независимо от типа этих данных. Это правило говорит о том, что отсутствующие значения должны представляться значениями NULL (значения NULL описаны в главе 4) .

4. Правило динамического каталога. Описание базы данных должно быть представлено в том же виде, что и описание самих данных. Это правило говорит о том, что реляционная базы данных должна сама себя описывать, т. е. содержать набор системных таблиц, описывающих саму структуру базы данных .

5. Правило исчерпывающего подъязыка базы данных. Реляционная база данных может поддерживать различные языки и способы взаимодействия с пользователем .

Однако должен существовать по крайней мере один язык, инструкциями которого в соответствии с четко определенным синтаксисом можно описать следующие элементы:

• определение данных;

• обработку данных;

• определение представлений;

• идентификацию прав доступа;

• условия целостности данных;

• границы транзакций .

6. Правило обновления представлений. Все представления, которые теоретически возможно обновить, должны быть доступны для обновления .

1.. 15 Представления, по сути, являются виртуальными таблицами, позволяющими показывать пользователям фрагменты структуры базы данных. В MySQL работа с представлениями возможна, только начиная с версии 5.0, и рассматривается в главе 30 .

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

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

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

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

11. Правило независимости размещения. База данных не должна зависеть от особенностей системы, на которой она расположена. Суть данного правила заключается в том, что язык управления базой данных должен обеспечивать возможность работы с распределенными данными .

12. Если в реляционной базе данных есть низкоуровневый язык, то должна отсутствовать возможность использования его для обхода правил и условий целостности данных, сформулированных на языке высокого уровня. Это правило запрещает иные средства работы с базой данных, кроме ее внутреннего языка .

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

1.3 .

Развитие компьютерных сетей, а тем более рост популярности Интернета, сыграли серьезную роль в развитии СУБД. Если раньше и приложение, и СУБД находились на






Похожие работы:

«СВОДНЫЙ ОТЧЁТ №3 МАРТ 2017 ГОДА СО Ц И А Л Ь Н О Э КО Н О М И Ч ЕС КО Е РА З В И Т И Е И Б Л А Г О У С Т Р О Й С Т В О Г О Р О Д С К О Г О О К Р У ГА Х И М К И...»

«АНОО Иркутская Вальдорфская школа УТВЕРЖДЕНА На заседании Педагогической коллегии "25" августа 2017 г. Ведущий коллегии Кузнецова Л.Г. РАБОЧАЯ ПРОГРАММА Предмет Музыка Учебный год 2017 2018 Класс 5 Количество часов в...»

«Муниципальное общеобразовательное учреждение средняя общеобразовательная школа п. Пригородный Согласовано: Согласовано: Утверждено: Руководитель МО Заместитель директора по ВР Директор _ / Л.В.Куркина / С.С.Михайлова / В.А.Корсаков Протокол № Приказ № от от ПРОГРАММА КРУЖКА (ра...»

«Департамент культуры г. Москвы Государственное бюджетное образовательное учреждение дополнительного образования детей города Москвы Детская музыкальная школа имени Л. Бетхов...»

«I (e 4 Sn 3 7 Sl ) N :0 o 29 i n4 7 П сихология СО ВРЕМ ЕН Н А Я ЗА РУ БЕЖ Н А Я J a dr Po o f eey y u M i sl r n oo c l or go nn g F h 0.2 1№. Том 2o. 0l n 7, 2. o V СОВРЕМЕННАЯ ЗАРУБЕЖНАЯ ПСИХОЛОГИЯ Т. 6, № 2 / 2017 Тема номера: Кросс-культурные исследования в сфере детско-родительских отношений Тематические редакторы: Л.И. Эл...»

«РОССИЙСКАЯ ФЕДЕРАЦИЯ (19) (11) (13) RU 2 592 314 C1 (51) МПК E02D 27/08 (2006.01) ФЕДЕРАЛЬНАЯ СЛУЖБА ПО ИНТЕЛЛЕКТУАЛЬНОЙ СОБСТВЕННОСТИ (12) ОПИСАНИЕ ИЗОБРЕТЕНИЯ К ПАТЕНТУ 2015128452/03, 13.07.20...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Наука, образование, общество Сборник научных трудов по материалам международной научно-практической конференции 29 февраля 2016 г. Часть 2 Тамбов 2016 http://uco m.ru/c o Наука, образование, общество: сборник научных трудов по материалам международной научно-практической конференции...»




 
2019 www.mash.dobrota.biz - «Бесплатная электронная библиотека - онлайн публикации»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.