Создание базы данных в MySQL
Инструкция о том, как создать новую базу данных в MySQL несколькими способами, добавить пользователей и выдать им полномочия на доступ к базе.
Эта инструкция — часть курса «MySQL для новичков».
Смотреть весь курс
Введение
В этой небольшой инструкции мы покажем, как создать новую базу данных в MySQL несколькими способами, как добавить пользователей и выдать им полномочия на доступ к базе.
Подготовка
Перед началом работы у вас должен быть установлен и настроен MySQL-сервер. В этой статье мы не будем показывать, как это сделать. Если у вас еще нет готового сервера, почитайте нашу статью, там мы пошагово описали процесс установки и первоначальной настройки MySQL.
Мы будем работать с сервером, развернутым на виртуальной машине Selectel.
Так как это удаленный сервер, нам понадобится его внешний IP-адрес. В этих примерах мы будем использовать адрес 82.202.199.34.
Подключение к серверу и создание новой базы
Все операции будем показывать на двух примерах: консольный клиент и phpMyAdmin. Если у вас другой инструмент для подключения к серверу, почитайте его документацию или используйте SQL-команды, которые мы будем выполнять при работе через консольный клиент. Они универсальны и подойдут для любого инструмента.
Через консоль
Подключимся к удаленному серверу MySQL:
mysql -u root -h 82.202.199.34 -p
После ввода этой команды нужно ввести пароль от пользователя root, который вы указывали на этапе установки и первоначальной настройки СУБД.
Для начала посмотрим, какие уже есть созданные базы данных:
show databases;
+--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | sys | | test | +--------------------+
Это все служебные базы. Мы не будем их трогать, а создадим свою БД. Для этого выполним команду для создания новой базы данных MySQL:
CREATE DATABASE my_db_cli;
Снова посмотрим список всех баз:
show databases;
Видим, что наша БД появилась в списке:
+--------------------+ | Database | +--------------------+ | information_schema | | my_db_cli | | mysql | | performance_schema | | sys | | test | +--------------------+
Через phpMyAdmin
Чтобы указать сервер для подключения, нужно отредактировать файл config.inc.php. В зависимости от вашей ОС или дистрибутива Linux, этот файл может находиться в разных директориях, поэтому мы не будем указывать конкретный путь. Откройте файл и добавьте в него строчку:
$cfg['Servers'][$i]['host'] = '82.202.199.34';
Теперь откройте интерфейс phpMyAdmin и залогиньтесь на сервер. В левой части экрана находится список созданных баз данных. Мы видим уже созданную нами ранее базу my_db_cli.
Создадим еще одну базу. Для этого над списком БД нажмите кнопку «Создать БД».
Укажем имя новой базы, а кодировку оставим по умолчанию. В нашем примере это:
utf8mb4_unicode_ci.

База данных создана, и теперь она появилась в списке слева:

Настройка и проверка доступа к базе данных
Сейчас у нас есть только root-пользователь, который имеет полный доступ к серверу и может работать с любой БД. Нам нужно создать новых пользователей и выдать им полномочия, чтобы каждый мог работать только с одной базой.
Через консоль
Создадим нового пользователя:
CREATE USER 'user_cli'@'%' IDENTIFIED BY 'password';
Знак процента означает, что пользователь может подключаться к серверу с любого хоста. Теперь выдадим этому пользователю полный доступ на базу my_db_cli:
GRANT ALL PRIVILEGES ON my_db_cli.* TO 'user_cli'@'%' WITH GRANT OPTION;
Через phpMyAdmin
Теперь сделаем то же самое через phpMyAdmin. Переходим на вкладку «Учетные записи пользователей» и в нижней части экрана нажимаем «Добавить учетную запись пользователя».

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

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

На следующем экране нужно указать привилегии. Мы хотим дать полный доступ к базе, поэтому выберем пункт «Отметить все».

Теперь проверим полномочия на примере одного пользователя. Для этого залогинимся под пользователем user_cli и попробуем получить доступ к обеим базам данных.
Подключаемся к серверу:
mysql -u user_cli -h 82.202.199.34 -p
Попробуем выбрать БД, к которой нет доступа:
use my_db_gui;
ERROR 1044 (42000): Access denied for user 'user_cli'@'%' to database 'my_db_gui'
Теперь выберем базу, к которой есть доступ и попробуем создать в ней таблицу:
use my_db_cli; create table t(id int);
Ошибок не возникло, значит полномочия настроены правильно.
Удаление базы данных
Теперь покажем, как удалить созданные БД. Учтите, что при удалении базы также удаляются все таблицы с данными в ней, поэтому будьте аккуратны и перепроверяйте названия баз, которые собираетесь удалить.
Через консоль
drop database my_db_cli;
Через phpMyAdmin
Выбираем нужную БД, переходим на вкладку «Операции» и нажимаем «Удалить базу данных».

Заключение
Вы узнали, как с помощью командной строки или phpMyAdmin можно выполнить создание новой БД в MySQL, как создавать пользователей и добавлять им права доступа.
Как установить и настроить MySQL в Ubuntu 20.04
Основы правил проектирования базы данных
Как это часто бывает, архитектору БД нужно разработать базу данных под конкретное решение.
Однажды в пятницу вечером, возвращаясь на электричке домой с работы, я подумал о том, как бы я создал сервис по найму сотрудников в разные компании. Ведь ни один из существующих сервисов не позволяет быстро понять насколько подходит тебе кандидат. Нет возможности создать сложные фильтры, включающие или исключающие совокупность определенных навыков, проектов или позиций. Максимум, что обычно предлагают сервисы — фильтры по компаниям и частично по навыкам.
В данной статье я позволю себе немного разбавить строгое изложение материала, смешав техническую информацию с не техническими примерами из жизни.
Для начала, разберем создание базы данных в MS SQL Server для сервиса поиска соискателей на работу.
Этот материал можно перенести и на другую СУБД такую как MySQL или PostgreSQL.
Основы правил проектирования
Для проектирования схемы базы данных, нужно вспомнить 7 формальных правил и саму концепцию нормализации и денормализации. Они и лежат в основе всех правил проектирования.
Опишем более детально 7 формальных правил:
-
отношение один к одному:
1.1) с обязательной связью:
примером может выступать гражданин и его паспорт: у любого гражданина должен быть паспорт; паспорт один для каждого гражданина
Реализовать данную связь можно двумя способами:
1.1.1) в одной сущности (таблице):

Рис.1. Сущность Citizen
Здесь таблица Citizen представляет собой сущность гражданина, а атрибут (поле) PassportData содержит все паспортные данные гражданина и не может быть пустым (NOT NULL).
1.1.2) в двух разных сущностях (таблицах):

Рис.2. Отношение сущностей Citizen и PassportData
Здесь таблица Citizen представляет собой сущность гражданина, а таблица PassportData — сущность паспортных данных гражданина (самого паспорта). Сущность гражданина содержит атрибут (поле) PassportID, который ссылается на первичный ключ таблицы PassportData. В свою очередь сущность паспортных данных содержит атрибут (поле) CitizenID, которое ссылается на первичный ключ CitizenID таблицы Citizen. Поле PassportID таблицы Citizen не может быть пустым (NOT NULL). Также здесь важно поддерживать целостность поля CitizenID таблицы PassportData, чтобы обеспечить связь один к одному. Иными словами, поле PassportID таблицы Citizen и поле CitizenID таблицы PassportData должны ссылаться на одни и те же записи как если бы это была одна сущность (таблица), представленная в пункте 1.1.1.
1.2) с необязательной связью:
примером может выступать человек, имеющий или не имеющий паспорт конкретной страны. В первом случае он будет являться гражданином рассматриваемой страны, а во втором — нет.
Реализовать данную связь можно двумя способами:
1.2.1) в одной сущности (таблице):

Рис.3. Сущность Person
Таблица Person представляет собой сущность человека, а атрибут (поле) PassportData содержит все его паспортные данные и может быть пустым (NULL).
1.2.2) в двух сущностях (таблицах):

Рис.4. Отношение сущностей Person и PassportData
Таблица Person представляет собой сущность человека, а таблица PassportData — сущность паспортных данных человека (самого паспорта). Сущность человека содержит атрибут (поле) PassportID, который ссылается на первичный ключ таблицы PassportData. В свою очередь сущность паспортных данных содержит атрибут (поле) PersonID, которое ссылается на первичный ключ PersonID таблицы Person. Поле PassportID таблицы Person может быть пустым (NULL). Здесь также важно поддерживать целостность поля PersonID таблицы PassportData. Это нужно, чтобы обеспечить связь один к одному. Поле PassportID таблицы Person и поле PersonID таблицы PassportData должны ссылаться на одни и те же записи как если бы это была одна сущность (таблица), показанная в пункте 1.2.1. Или же данные поля должны быть неопределенными, то есть, содержать NULL.
отношение один ко многим:
2.1) с обязательной связью:
примером могут выступать родитель и его дети. У каждого родителя есть как минимум один ребенок.
Реализовать данную связь можно двумя способами:
2.1.1) в одной сущности (таблице):

Рис.5. Сущность Parent
Таблица Parent представляет сущность родителя, а атрибут (поле) ChildList содержит информацию о детях. Данное поле не может быть пустым (NOT NULL). Обычно типом поля ChildList выступают неполно структурированные данные (NoSQL) такие как XML, JSON и т д.
2.1.2) в двух сущностях (таблицах):

Рис.6. Отношение сущностей Parent и Child
Таблица Parent представляет сущность родителя, а таблица Child — сущность ребенка. У таблицы Child есть поле ParentID, ссылающееся на первичный ключ ParentID таблицы Parent. Поле ParentID таблицы Child не может быть пустым (NOT NULL).
2.2) с необязательной связью:
примером может выступать человек, у которого могут быть дети или их может не быть.
Реализовать данную связь можно двумя способами:
2.2.1) в одной сущности (таблице):

Рис.7. Сущность Person
Таблица Parent представляет сущность родителя, а атрибут (поле) ChildList содержит информацию о детях. Данное поле может быть пустым (NULL). Обычно типом поля ChildList выступают неполно структурированные данные (NoSQL) такие как XML, JSON и т д.
2.2.2) в двух сущностях (таблицах):

Рис.8. Отношение сущностей Person и Child
Таблица Parent представляет сущность родителя, а таблица Child — сущность ребенка. У таблицы Child есть поле ParentID, ссылающееся на первичный ключ ParentID таблицы Parent. Поле ParentID таблицы Child может быть пустым (NULL).
2.2.3) в одной сущности со ссылкой на саму себя при условии, что у сущностей (таблиц) родителя и ребенка будут одинаковые наборы атрибутов (полей) без учета ссылки на родителя:

Рис.9. Сущность Person со связью на саму себя
Сущность (таблица) Person содержит атрибут (поле) ParentID, который ссылается на первичный ключ PersonID этой же таблицы Person и может содержать пустое значение (NULL).
Примером может выступить недвижимость: она может быть в собственности как одного человека, так и нескольких. С другой стороны, один человек может владеть несколькими домами или долями нескольких домов.
Реализовать данное отношение, с привлечением NoSQL, можно так же, как в описанных выше отношениях. Однако, в рамках реляционной модели обычно такое отношение реализуют через 3 сущности (таблицы):

Рис.10. Отношение сущностей Person и RealEstate
Таблицы Person и RealEstate представляют соответственно сущности человека и недвижимости. Связываются данные сущности (таблицы) через сущность (таблицы) PersonRealEstate. Атрибуты (поля) PersonID и RealEstateID ссылаются на первичные ключи PersonID таблицы Person и RealEstateID таблицы RealEstate соответственно. Обратите внимание, что для таблицы PersonRealEstate пара (PersonID; RealEstateID) всегда является уникальной и потому может выступать первичный ключем для самой связующей сущности PersonRealEstate.
А где же семь формальных правил?
- п.1 (п.1.1 и п.1.2) — первое и второе формальные правила
- п.2 (п.2.1 и п.2.2) — третье и четвертое формальные правила
- п.3 (аналогично п.2) — пятое и шестое формальные правила
- п.4 — седьмое формальное правило
Говоря о нормализации, нужно понимать ее суть. Нормализация ведет к уменьшению повторяемости хранения информации, а следовательно и к уменьшению возможности появления аномалий в данных. Однако, нормализация при дроблении сущностей приводит к более сложным построениям запросов для манипуляций с данными (вставки, модификации, выборки и удаления).
Обратным процессом нормализации называется денормализация. Это упрощение построения запросов доступа к данным за счет укрупнения и вложенности сущностей (например, как было показано выше в пунктах 2.1.1 и 2.2.1 с помощью неполно-структурированных данных (NoSQL)).
Вот и вся суть правил проектирования баз данных.
А вы уверены, что поняли отношения в семи формальных правилах? Именно поняли, а не узнали? Ведь знать и понимать — две совершенно разных концепции.
Объясню более детально. Спросите себя, можете ли вы за пару часов набросать пусть и укрупненную по сущностям, но модель базы данных для любой предметной области и для любой информационной системы? (тонкости и детали можно достроить, поспрашивав аналитиков и представителей заказчиков). Если вопрос вас удивил, и вы думаете, что это невозможно, значит вы знаете семь формальных правил, но не понимаете их.
Почему-то многие источники игнорируют тот факт, что эти отношения были не придуманы, а выявлены. Они изначально существуют в реальном мире как между субъектами, так и между субъектами и объектами.
Также, эти отношения могут меняться, переходя из один к одному к одному ко многим, многие к одному или многие ко многим. Обязательность связи может меняться или остаться неизменной.
Позволю себе рассказать об одном случае, когда от знания семи формальных правил я пришел именно к пониманию этих отношений.
В свое время меня смущало то, что в ВУЗе я знал эти семь формальных правил, но на производственной практике (ВУЗ отправляет студентов в различные компании для приобретения профессионального опыта) очень долго строил модели баз для разных предметных областей. Я задумался и понял, что не понимаю этих отношений.
Мне помогло наблюдение за людьми, а суть отношений раскрылась в сновидении. Этот сон я перескажу в упрощенной форме: только то, что позволяет лучше понять именно эти семь формальных правил — без детализации всего остального.
Сон был про семью, в которой есть отец, мать и дети. Отец погибает в автомобильной катастрофе, а мать начинает пить, и детей в итоге забирают в детский дом. Эти дети надолго остаются без родителей. Затем у некоторых детей появляются попечители, их тоже несколько.
Вы проследили, какие отношения были между субъектами, и как менялись эти отношения?
Давайте присмотримся внимательнее.
- Когда семья была полной, с несколькими детьми, отношение между родителями и детьми имело вид многие ко многим.
- Когда остались мать и дети, отношение между родителем и детьми стало один ко многим с обязательной связью. Однако, в любой семье, где может и не быть детей, это отношение будет таким же, но уже с необязательной связью.
- А вот со стороны детей отношение к родителю было как многие к одному с обязательной связью пока родителя не лишили родительских прав.
- Когда дети оказались в детском доме — отношение изменилось на многие к одному с необязательной связью.
- Когда у детей появились попечители, связь между ними стала многие ко многим: у каждого попечителя могут быть другие подопечные дети, а у каждого ребенка могут быть другие попечители (родители).
Надеюсь, теперь вы значительно приблизились к пониманию этих семи формальных правил.
Стоит постоянно практиковаться: наблюдать за людьми и выявлять существующие отношения как между субъектами, так и между субъектами и объектами. Выше описывался гражданин и его паспорт как отношение один к одному с обязательной связью. В тоже время, пример человека и его паспорта — это отношение один к одному с необязательной связью.
Поняв семь формальных правил, вы сможете без труда спроектировать модель базы данных любой сложности для любой информационной системы.
Также вы увидите, что реализовать отношение можно разными способами, а сами отношения могут меняться. Модель (схема) базы данных — это «снимок» отношений между сущностями в определенный момент времени. Именно поэтому важно определить как сами сущности — образы объектов из реального мира или предметной области, так и их отношения между собой с учетом изменений в будущем.
Хорошо спроектированную модель базы данных с учетом изменения отношений в реальности или в предметной области не понадобится менять годами или даже десятилетия. Это особенно важно для хранилищ данных, где изменения влекут пересохранение больших объемов данных (от нескольких гигабайт до многих терабайт).
Важно запомнить, что таблицы в реляционной модели — это отношения сущностей, а строки (кортежи) — это экземпляры этих отношений. Но чтобы было проще, под таблицами часто понимаются сущности, а под строками таблицы — экземпляры сущностей. Их отношения выражаются через связи в форме внешних ключей.
Проектирование схемы базы данных для поиска соискателей на работу
После того, как мы описали основы правил проектирования БД в первой части, давайте создадим схему базы данных для поиска соискателей на работу.
Для начала, определим, что важно для сотрудников из компании, которые ищут кандидатов:
- Сотрудник (Employee)
- Компания (Company)
- Позиция (должность) (Position)
- Проект (Project)
- Навык (Skill)
- Компании и сотрудники относятся как многие ко многим, так как сотрудник мог работать в нескольких компаниях, а в компании работают многие люди.
- Аналогично относятся позиции и сотрудники: несколько сотрудников могут занимать одну позицию как в рамках как одной, так и нескольких компаний.
- С другой стороны, сотрудник мог работать на разных позициях как в рамках одной, так разных компаний. Таким образом, отношение между позициями и компаниями — многие ко многим.
- Аналогично и по проектам: проекты относятся ко всем выше рассмотренным сущностям как многие ко многим.
- Для простоты будем считать, что в проекте сотрудник использует один набор навыков.
- Тогда проекты и навык относятся как многие ко многим.

Рис.11. Схема базы данных для поиска соискателей на работу
Здесь таблица JobHistory выступает как сущность истории работы каждого соискателя. То есть, это резюме, которое педставляет отношения многие ко многим между сущностями сотрудник, компания, позиция и проект.
Проекты и навыки относятся друг другу как многие ко многим и потому связываются между собой через сущность (таблицу) ProjectSkill.
Когда вы понимаете отношения между субъектами и между субъектами и объектами — уже упомянутые семь формальных правил — эту или схожую схему можно реализовать «на коленке»: на листке бумаги, мене чем за час. И это еще с учетом усталости после плодотворного рабочего дня.
Здесь можно было упростить схему добавления данных, если «навыки» вложить в сущность «проекты» через неполно структурированные данные (NoSQL) в виде XML, JSON или просто перечислять названия навыков через точку с запятой. Но это бы усложнило выборку с группировкой по навыкам и фильтрацию по отдельным навыкам.
Подобная модель лежит в основе базы данных проекта Geecko.
Как видите, ничего сложного в проектировании информационных систем в части проектирования базы данных нет. Это всего лишь отражение объектов и субъектов из реальности, перенесенное в «сущности» схемы базы данных. Отношения между этими сущностями фиксируются на определенный момент времени, с учетом будущих изменений.
Что именно мы возьмем из реальности и вложим в сущность схемы, и какие отношения построим в модели, будет зависеть от того, что мы хотим от информационной системы в общем, здесь и в будущем. Иными словами — какие данные мы хотим получить в текущий момент времени и через определенное время в будущем.
Немного лирики
После того, как вы внедрите модель в работу, остановитесь на миг и подумайте: только что был создан новый маленький мир. В нем есть свои сущности из реального мира и свои отношения. Да, это цифровой мир, но он теперь будет развиваться своей дорогой. Он будет общаться (интегрироваться) с другими системами (мирами), тоже созданными по своим правилам. Данные будут течь в этих системах, как кровь в живом организме.
А перед сном подумайте о том, что семь формальных правил были всегда, и что они окружают нас всюду. Не больше и не меньше, всегда семь. Все отношения реальной жизни можно разложить на эти семь формальных правил. А когда вы думаете или видите сны, как там сущности относятся друг к другу — не по тем же семи формальным правилам?
Вообще, я уверен, что эти отношения (семь формальных правил) выявил очень хороший психотерапевт, возможно — женщина. Это было очень давно, задолго до появления самого понятия информационных технологий. И самое интересное, что эти отношения живут вне базы данных и ИТ — последние лишь используют их для моделирования информационных систем.
Но мы немного отошли от темы. Я лишь призываю в момент создания новой системы подойти к этому процессу с душой. И тогда поверьте, случится момент творения. Спроектированная таким образом система будет живее всех живых в цифровом мире.
Послесловие
Диаграммы для примеров были реализованы с помощью инструмента Database Diagram Tool for SQL Server. Однако, подобный функционал есть и в DBeaver.
Источники
- SQL Database Design Basics with Example
- Geecko
- Microsoft SQL documentation
- SSMS
- Database Diagram Tool for SQL Server
SQL — Урок 1. Создание базы данных и таблиц
Итак, вы установили MySQL, и мы начинаем осваивать язык SQL. В уроке 3 по основам баз данных, мы создали концептуальную модель маленькой БД для форума. Пришло время реализовать ее в СУБД MySQL.
Для этого прежде всего надо запустить сервер MySQL. Идем в системное меню Пуск — Программы — MySQL — MySQL Server 5.1 — MySQL Command Line Client. Откроется окно, предлагающее ввести пароль.
Нажимаем Enter на клавиатуре, если вы не указывали пароль при настройке сервера или указываем пароль, если вы его задавали. Ждем приглашения mysql>.
Нам надо создать базу данных, которую мы назовем forum. Для этого в SQL существует оператор create database. Создание базы данных имеет следующий синтаксис:
create database имя_базы_данных;
Максимальная длина имени БД составляет 64 знака и может включать буквы, цифры, символ «_» и символ «$». Имя может начинаться с цифры, но не должно полностью состоять из цифр. Любой запрос к БД заканчивается точкой с запятой (этот символ называется разделителем — delimiter). Получив запрос, сервер выполняет его и в случае успеха выдает сообщение «Query OK . «
Итак, создадим БД forum:
Нажимаем Enter и видим ответ «Query OK . «, означающий, что БД была создана:
Вот так все просто. Теперь в этой базе данных нам надо создать 3 таблицы: темы, пользователи и сообщения. Но перед тем, как это делать, нам надо указать серверу в какую именно БД мы создаем таблицы, т.е. надо выбрать БД для работы. Для этого используется оператор use. Синтаксис выбора БД для работы следующий:
use имя_базы_данных;
Итак, выберем для работы нашу БД forum:
Нажимаем Enter и видим ответ «Database changed» — база данных выбрана.
Выбирать БД необходимо в каждом сеансе работы с MySQL.
Для создания таблиц в SQL существует оператор create table. Создание базы данных имеет следующий синтаксис:
create table имя_таблицы (имя_первого_столбца тип, имя_второго_столбца тип, . имя_последнего_столбца тип );
Требования к именам таблиц и столбцов такие же, как и для имен БД. К каждому столбцу привязан определенный тип данных, который ограничивает характер информации, которую можно хранить в столбце (например, предотвращает ввод букв в числовое поле). MySQL поддерживает несколько типов данных: числовые, строковые, календарные и специальный тип NULL, обозначающий отсутствие информации. Подробно о типах данных мы будем говорить в следующем уроке, а пока вернемся к нашим таблицам. В них у нас всего два типа данных — целочисленные значения (int) и строки (text). Итак, создадим первую таблицу — Темы:
Нажимаем Enter — таблица создана:
Итак, мы создали таблицу topics (темы) с тремя столбцами:
id_topic int — id темы (целочисленное значение),
topic_name text — имя темы (строка),
id_author int — id автора (целочисленное значение).
Аналогичным образом создадим оставшиеся две таблицы — users (пользователи) и posts (сообщения):
Итак, мы создали БД forum и в ней три таблицы. Сейчас мы об этом помним, но если наша БД будет очень большой, то удержать в голове названия всех таблиц и столбцов просто невозможно. Поэтому надо иметь возможность посмотреть, какие БД у нас существуют, какие таблицы в них присутствуют, и какие столбцы эти таблицы содержат. Для этого в SQL существует несколько операторов:
show databases — показать все имеющиеся БД,
show tables — показать список таблиц текущей БД (предварительно ее надо выбрать с помощью оператора use),
describe имя_таблицы — показать описание столбцов указанной таблицы.
Давайте попробуем. Смотрим все имеющиеся базы данных (у вас она пока одна — forum, у меня 30, и все они перечислены в столбик):
Теперь посмотрим список таблиц БД forum (для этого ее предварительно надо выбрать), не забываем после каждого запроса нажимать Enter:
В ответе видим названия наших трех таблиц. Теперь посмотрим описание столбцов, например, таблицы topics:
Первые два столбца нам знакомы — это имя и тип данных, значения остальных нам еще предстоит узнать. Но прежде мы все-таки узнаем какие типы данных бывают, какие и когда следует использовать.
А сегодня мы рассмотрим последний оператор — drop, он позволяет удалять таблицы и БД. Например, давайте удалим таблицу topics. Так как мы два шага назад выбирали БД forum для работы, то сейчас ее выбирать не надо, можно просто написать:
drop table имя_таблицы;
Теперь снова посмотрим список таблиц нашей БД:
Наша таблица действительно удалена. Теперь давайте удалим и саму БД forum (удаляйте, не жалейте, ее все равно придется переделывать). Для этого напишем:
drop database имя_базы данных;
И убедитесь в этом, сделав запрос на все имеющиеся БД:
У вас, наверно, нет ни одной БД, у меня их стало 29 вместо 30.
На сегодня все. Мы научились создавать базы данных и таблицы, удалять их и извлекать информацию об имеющихся базах данных, таблицах и их описаниях.
Научись программировать на Python прямо сейчас!
- Научись программировать на Python прямо сейчас
- Бесплатный курс
Если этот сайт оказался вам полезен, пожалуйста, посмотрите другие наши статьи и разделы.
Основы работы с базами SQL

В программировании и IT часто приходится работать с базами данных. Это специальные электронные массивы (таблицы) с информацией упорядоченного характера.
В данной статье речь зайдет о том, как создать базу данных SQL. Дополнительно будут затронуты основы работы с БД.
Предварительная подготовка и общий план
Лучше всего создавать рассматриваемые элементы при помощи Microsoft SQL Server. Для этого необходимо провести небольшую предварительную подготовку:
- Установить СУБД Microsoft SQL Server. Новичкам подойдет версия Express.
- Удостовериться в наличии на компьютере SQL Server Management Studio (SSMS). Он является основным инструментом, который помогает разрабатывать баз данных MS SQL Server. Среда полностью бесплатная.
- Сформировать (спроектировать) изначальную базу данных. Перед тем, как проводить создание проекта в электронном виде, его нужно тщательно продумать. В процессе планирования рекомендуется определиться с сущностями, хранимыми в «таблице». Сюда же относят характеристики, свойства, ограничения, а также иные правила отображения и классификации. Все это поможет сделать БД максимально удобной и эффективной.
- Создать пустую БД. В SSMS процедура реализовывается несколькими методами: через графический интерфейс, а также посредством языка T-SQL.
- Создать таблицы. Обычно на данном этапе уже есть готова БД, но без внесенных в нее сведений. Этот шаг характеризуется не только формированием таблиц, но и заданием тех или иных ограничений.
- Наполнить «массив» информацией.
- Создать иные databases объекты. Сюда включены функции, триггеры, процедуры.
Это – общий алгоритм. Перед тем, как приступать к активным действиям, нужно тщательно изучить Microsoft SQL Server, а также язык T-SQL или MySQL. В противном случае при реализации поставленной задачи не исключены серьезные проблемы.
Создание пустой базы
Создание базы данных – не самый сложный процесс, если действовать последовательно. Заострим внимание на формирование пустой БД. Данный вариант предусматривает два способа реализации – через специализированный язык, а также при помощи встроенного графического интерфейса.
Графический интерфейс
Для того, чтобы воспользоваться соответствующим алгоритмом, необходимо:
- Запустить Server Management Studio.
- Подключиться к серверу.
- Открыть обозреватель объектов и кликнуть по блоку «Базы данных» правой кнопкой мыши. В появившемся меню выбрать команду «create database».
- Изучить появившееся меню. Обязательным для заполнения является только поле «Имя базы данных». Оставшиеся параметры можно заполнить по мере необходимости.
- Нажать на кнопку «Ок».
Среда вследствие выполнения описанного алгоритма создает базу данных без внесенных в нее сведений. Если объект с указанным в свойствах ранее именем отсутствует, он будет сформирован и отображен в обозревателе.
Через T-SQL
Второй вариант, помогающий сделать новую базу данных – это использование T-SQL. Он еще более простой, чем действия при помощи графического интерфейса. Достаточно указать специальную команду на языке запросов:
- Открыть редактор SQL-запросов. Для этого нужно кликнуть на панели инструментов по кнопке «Создать запрос».
- Ввести инструкцию: create database nameDB. NameDB – это имя БД.
- Нажать на кнопку «Выполнить».
Произойдет creating database. Это элементарный вариант. Таким способом можно сделать БД, которая будет обладать теми же характеристиками и параметрами, что и при использовании графического интерфейса.
Выше – наглядный пример того, как создается TestDB в каталоге DataBases на разделе жесткого диска с именем D.
В MySQL
В MySQL делать БД тоже достаточно легко. Для этого используется оператор create database. После него нужно указать имя создаваемого объекта при помощи create schema.
Выше – пример created database MySampleDB. Для того, чтобы исключить конфликты имен, можно использовать опцию if not exists. Эта «команда» создаст БД только тогда, когда ее название является уникальным.
Удаление
Иногда возникает потребность в удалении БД. В реальной жизни подобные ситуации возникают редко, но знать о дальнейших действиях при подобных обстоятельствах нужно.
Удаление может производиться так, как и creates – через графический интерфейс, а также при помощи специальных команд и операторов. В первом случае потребуется:
- Открыть «Обозреватель объектов».
- Найти интересующий элемент и кликнуть правой кнопкой мыши по нему.
- Выбрать команду «Удалить». Откроется меню удаления.
- Выбрать объекты (если их несколько), а затем подтвердить операцию. На данном этапе рекомендуется поставить отметку около пункта «Закрыть существующие соединения». Это поможет избавиться от существующих подключений.
Удалить базу данных можно только тогда, когда с ней никто не работает. Это касается не только сторонних пользователей, но и самой SSMS.
Если нужно избавиться от БД при помощи T-SQL, подойдет команда:
Здесь можно увидеть больше информации о том, как грамотно работать с созданием БД в Microsoft Server.
