Понятие и назначение базы данных. примеры и классификация баз данных

SQL и MySQL

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

Что же можно делать при помощи этого языка? Создавать и менять структуру базы, сортировать, добавлять новые записи и так далее. Однако, не все так просто. Зная язык программирования его нужно еще и применять каким-то образом.

Зная html и css многие все равно обращаются к таким программам как Dreamweaver или Notepad++, чтобы было удобнее и быстрее работать. В конце концов они открывают хотя бы обычный блокнот, чтобы выполнять эти операции.

С SQL точно также. Для того чтобы его использовать, на хостинге устанавливается MySQL, через которую и ведется вся работа.

Поведем итоге. Существует множество типов баз данных, но самой популярной признана реляционная. Для работы с ней необходимо знать язык программирования SQL и хоть он не единственный язык, но, опять же, самый распространенный. И наконец вы можете обойтись без MySQL, в интернете достаточно и других программ, но работать с ней будет легче.

Достоинства документных баз

• Позволяют хранить объекты с разной структурой.
• Могут отображать почти все структуры данных, включая объекты на основе ООП, списки и словари, используя старый добрый JSON.
• Несмотря на то, что NoSQL не схематичны по своей природе, они часто поддерживают проверку схемы. Это значит, что вы можете сделать коллекцию со схемой. Эта схема не будет простой, как таблица: это будет JSON схема со специфическими полями.
• Запросы к NoSQL очень быстрые — каждая запись независима и, следовательно, время запроса не зависит от размера базы. По той же причине эта БД поддерживает параллельность.
• В NoSQL масштабирование БД осуществляется добавлением компьютеров и распределением данных между ними, этот метод называется горизонтальное масштабирование. Оно позволяет автоматически добавлять ресурсы к БД, когда нам нужно, не провоцируя простои.

Что может храниться в MySQL

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

Например, все наши статьи в «Коде» хранятся в MySQL-базе, с которой мы работаем через Вордпресс. Там же есть информация и об авторах, и о картинках для статей, о дате публикации и о многом другом. Чтобы вы прочитали эту статью, сайт обратился к базе данных, взял оттуда статью, правильно её обработал и показал вам.

Другие используют MySQL для работы с клиентской базой — в бизнесе, поликлиниках или системах учёта товаров. 

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

Создание связей между сущностями

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

Каждый объект может быть взаимосвязан с другим с помощью одного из трех типов связи:

Связь «один-к одному»

Когда существует только один экземпляр объекта A для каждого экземпляра объекта B, говорят, что между ними существует связь «один-к одному» (часто обозначается 1:1). Можно указать этот тип связи в ER-диаграмме линией с тире на каждом конце:

Если при проектировании и разработке баз данных у вас нет оснований разделять эти данные, связь 1:1 обычно указывает на то, что в лучше объединить эти таблицы в одну.

Но при определенных обстоятельствах целесообразнее создавать таблицы со связями 1:1. Если есть поле с необязательными данными, например «описание», которое не заполнено для многих записей, можно переместить все описания в отдельную таблицу, исключая пустые поля и улучшая производительность базы данных.

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

Связь «один-ко-многим»

Эта связи возникают, когда запись в одной таблице связана с несколькими записями в другой. Например, один клиент мог разместить много заказов, или у читателя может быть сразу несколько книг, взятых в библиотеке. Связи «один- ко-многим» (1:M) обозначаются так называемой «меткой ноги вороны», как в этом примере:

Чтобы реализовать связь 1:M, добавьте первичный ключ из «одной» таблицы в качестве атрибута в другую таблицу. Если первичный ключ таким образом указан в другой таблице, он называется внешним ключом. Таблица со стороны связи «1» представляет собой родительскую таблицу для дочерней таблицы на другой стороне.

Связь «многие-ко-многим»

Когда несколько объектов таблицы могут быть связаны с несколькими объектами другой. Говорят, что они имеют связь «многие-ко-многим» (M:N). Например, в случае студентов и курсов, поскольку студент может посещать много курсов, и каждый курс могут посещать много студентов.

На ER-диаграмме эти связи отображаются с помощью следующих строк:

При проектировании структуры базы данных реализовать такого рода связи невозможно. Вместо этого нужно разбить их на две связи «один-ко-многим».

Для этого нужно создать между этими двумя таблицами новую сущность. Если между продажами и продуктами существует связь M:N, можно назвать этот новый объект «sold_products», так как он будет содержать данные для каждой продажи. И таблица продаж, и таблица товаров будут иметь связь 1:M с sold_products. Этот вид промежуточного объекта в различных моделях называется таблицей ссылок, ассоциативным объектом или таблицей связей.

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

Обязательно или нет?

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

Два объекта могут быть взаимозависимыми (один не может существовать без другого).

Рекурсивные связи

Иногда при проектировании базы данных таблица указывает на себя саму. Например, таблица сотрудников может иметь атрибут «руководитель», который ссылается на другое лицо в этой же таблице. Это называется рекурсивными связями.

Лишние связи

Лишние связи — это те, которые выражены более одного раза

Как правило, можно удалить одну из таких связей без потери какой-либо важной информации. Например, если объект «ученики» имеет прямую связь с другим объектом, называемым «учителя», но также имеет косвенные отношения с учителями через «предметы», нужно удалить связь между «учениками» и «учителями»

Так как единственный способ, которым ученикам назначают учителей — это предметы.

2 Построение концептуальной модели

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

На диаграмме выделены роли кассира и менеджера, а также основные отношения между сущностями. На диаграмме нет роли администратора, но его роль заключается в:

1. создании всех таблиц базы;
2. добавлении залов и рядов в них;
3. добавлении кассиров и менеджеров.

На диаграмме не отражена роль посетителя, так как:

1. билет не содержит информации о том, кто его купил (посетитель может подарить билет другу);
2. система вообще не хранит информацию о посетителях;
3. покупку билета он осуществляет через общение с кассиром вне системы;
4. никакие данные в базе посетитель самостоятельно изменить не может.

На диаграмме проставлены кратности связей, например, видно, что один менеджер может добавить много (N) прокатов. В этой базе не оказалось связей типа N:M, сложных или рекурсивных связей — такие связи являются препятствиями в проектировании и решаются изменением ее структуры.

Для формирования схемы данных необходимо сначала дополнить ER-диаграмму реквизитами сущностей (уточнить ее) — результат приведен на рисунке.

• система не должна позволять продавать несколько билетов на одно и то же место при одном показе фильма. Это значит, что вторичным ключем для Билета должен быть кортеж (id_screening, row, seat). Однако, тогда нет необходимости в id билета — на билеты не ссылается ни одна таблица, это поле может быть удалено. Изначально id был добавлен потому, что обычно на билетах в кинотеатрах печатается номер;
• билет хранит поле id_hall, это было сделано для того, чтобы посетитель кинотеатра мог найти свой кинозал. Однако, билет, выдаваемый пользователю — это не тоже самое, что информация о билетах, хранимая в базе данных. Билет базы данных хранит также поле id_screening, а Показ уже ссылается на id_hall. Таким образом, в базе нет смысла хранить id_hall в таблице билетов.

Исправленная ER-диаграмма приведена ниже:

Таблица менеджеров и кассиров не объединены в таблицу Users так как вопросы разграничения прав доступа в различных СУБД решаются по-разному. Так, в MS SQL пользователи добавляются с помощью специальных запросов типа:

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

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

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

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

Эдгар Кодд сформулировал 12 законов, на которых строится реляционная база данных SQL. Не хочу грузить вас этими правилами, они не так уж важны и я боюсь, что простым языком их никак не объяснить

В конце концов, важно лишь понять основные принципы

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

Предположим у вас есть таблица с несколькими графами: порядковый номер (код), название книги и ее расположение (слева, справа на полке).

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

Чтобы каждый раз не писать «слева» и «справа», ведь числа читать проще не только нам, но и машинам. Существует другая таблица, в которой обозначено лево – цифрой 1, а право – 2. В итоге, третья колонка у нас состоит только из этих обозначений: 1 и 2, но чтобы получить расшифровку, нужно обратиться к третьей таблицу, получить внешний ключ.

Именно на этом принципе и строятся реляционные таблицы. Все они взаимосвязаны. Без одной вам не получить информацию о другой.

Хранение ссылок на объекты

При манипулировании данными, хранящимися в базе данных «1С:Предприятия 8», зачастую используется объектный подход. Это значит, что обращение (чтение и запись) к некоторой совокупности данных, хранящихся в базе, происходит как к единому целому. Например, используя объектную технику, можно манипулировать данными справочников, документов, планов видов характеристик, планов счетов и т.д.

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

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

Что такое язык SQL

Чтобы работать с реляционной базой данных, нужно знать специальный язык запросов — SQL. Это расшифровывается как structured query language — язык структурированных запросов. «Структурированный» означает, что каждый запрос должен иметь определённую структуру, чтобы база поняла, как на него реагировать. 

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

С помощью запросов можно делать что угодно: 

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

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

Определение сущностей

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

Сущность — это объект в базе данных, в котором хранятся данные. Сущность может представлять собой нечто вещественное (дом, человек, предмет, место) или абстрактное (банковская операция, отдел компании, маршрут автобуса). В физической модели сущность называется таблицей.

Сущности состоят из атрибутов (столбцов таблицы) и записей (строк в таблице).

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

Любая таблица имеет следующие характеристики:

• в ней нет одинаковых строк;
• все столбцы (атрибуты) в таблице должны иметь разные имена;
• элементы в пределах одной колонки имеют одинаковый тип (строка, число, дата);
• порядок следования строк в таблице может быть произвольным.

На этом этапе вам необходимо выявить все категории информации (сущности), которые будут храниться в базе данных.

5 последних уроков рубрики «Разное»

• Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.

• Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

  Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

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

• Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Создание таблиц и ключей с помощью конструктор таблиц

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

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

1. В Обозреватель сервера разверните узел подключения к данным , а затем узел сампледатабасе. mdf .

   если не удается развернуть узел подключения к данным или отсутствует подключение сампледатабасе. mdf, нажмите кнопку Подключение к базе данных на панели инструментов обозреватель сервера. в диалоговом окне добавление соединения убедитесь, что в поле источник данных выбран Microsoft SQL Server файл базы данных , а затем найдите и выберите файл сампледатабасе. mdf. Завершите добавление подключения, нажав кнопку ОК.

2. Щелкните правой кнопкой мыши таблицы и выберите команду Добавить новую таблицу.

   Будет открыт Конструктор таблиц, отобразится сетка с одной строкой по умолчанию, которая представляет один столбец в создаваемой таблице. Путем добавления строк в сетку будут добавлены столбцы в таблицу.

3. В сетке добавьте строку для каждой из следующих записей.

   Имя столбца	Тип данных	Разрешить значения null
   		False (не установлен)
   		False (не установлен)
   		True (установлен)
   		True (установлен)

4. Щелкните строку правой кнопкой мыши и выберите пункт Задать первичный ключ.

5. Щелкните строку по умолчанию () правой кнопкой мыши и выберите пункт Удалить.

6. Назовите таблицу «Клиенты» путем обновления первой строки в области скриптов, как показано в следующем примере:

   Отобразятся примерно следующие сведения:

7. В левом верхнем углу Конструктор таблиц выберите Обновить.

8. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

   Таблица Customers создается в файле локальной базы данных.

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

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

   Имя столбца	Тип данных	Разрешить значения null
   		False (не установлен)
   		False (не установлен)
   		True (установлен)
   		True (установлен)

2. Задайте OrderID в качестве первичного ключа, а затем удалите строку по умолчанию.

3. Назовите таблицу «Заказы» путем обновления первой строки в области скриптов, как показано в следующем примере:

4. В левом верхнем углу Конструктор таблиц выберите Обновить.

5. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

   Таблица Orders создается в файле локальной базы данных. Если развернуть узел таблицы в обозреватель сервера, отобразятся две таблицы:

Создание внешнего ключа

1. В контекстной области в правой части сетки конструктор таблиц для таблицы Orders щелкните правой кнопкой мыши внешние ключи и выберите Добавить новый внешний ключ.

2. В появившемся текстовом поле замените текст ToTable на Customers.

3. в области T-SQL обновите последнюю строку, чтобы она соответствовала следующему примеру:

4. В левом верхнем углу Конструктор таблиц выберите Обновить.

5. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

   Создается внешний ключ.

MongoDB

MongoDB была основана в 2007 году и известна как «база данных для великих идей». Проект финансируется такими известными инвесторами, как Fidelity Investments, Goldman Sachs Group, Inc., и Intel Capital. С момента своего создания MongoDB была скачена 20 миллионов раз и поддерживается более чем 1000 партнерами. Эти партнеры придерживаются принципа бесплатного решения с открытым исходным кодом.

Достоинства

• Проверка документов;
• Зашифрованный механизм хранения.

Популярные варианты использования:

• мобильные приложения;
• каталоги продуктов;
• управление контентом;
• Real-time приложения с механизмом хранения в памяти (бета-версия);
• сокращает время между первичным сбоем и восстановлением.

Недостатки

• Не подходит для приложений, требующих сложных транзакций;
• Не подходит для устаревших приложений;
• Молодое решение: программное обеспечение меняется и быстро развивается.

Создание и удаление базы данных

Последнее обновление: 09.07.2017

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

Для создания базы данных используется команда CREATE DATABASE.

Чтобы создать новую базу данных откроем SQL Server Management Studio. Нажмем на назначение сервера в окне Object
Explorer и в появившемся меню выберем пункт New Query.

В центральное поле для ввода выражений sql введем следующий код:

CREATE DATABASE usersdb

Тем самым мы создаем базу данных, которая будет называться «usersdb»:

Для выполнения команды нажмем на панели инструментов на кнопку Execute или на клавишу F5. И на сервере появится новая база данных.

После создания базы даных, мы можем установить ее в качестве текущей с помощью команды USE:

USE usersdb;

Прикрепление базы данных

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

CREATE DATABASE название_базы_данных
ON PRIMARY(FILENAME='путь_к_файлу_mdf_на_локальном_компьютере')
FOR ATTACH;

В качестве каталога для базы данных лучше использовать каталог, где хранятся остальные базы данных сервера. На Windows 10
по умолчанию это каталог C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA.
Например, пусть в моем случае файл с данными называется userstoredb.mdf. И я хочу этот файл добавить на сервер
как базу данных. Вначале его надо скопировать в выше указанный каталог. Затем для прикрепления базы к серверу надо использовать следующую команду:

CREATE DATABASE contactsdb
ON PRIMARY(FILENAME='C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\userstoredb.mdf')
FOR ATTACH;

После выполнения команды на сервере появится база данных contactsdb.

Удаление базы данных

Для удаления базы данных применяется команда DROP DATABASE, которая имеет следующий синтаксис:

DROP DATABASE database_name1 ...

После команды через запятую мы можем перечислить все удаляемые базы данных. Например, удаление базы данных contactsdb:

DROP DATABASE contactsdb

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

НазадВперед

Данные

Вокруг нас всегда много разных данных, например:

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

Если это компьютерная игра, то данными будут типы и местоположения врагов, их уровень здоровья, уровень здоровья героя, тип героя, его положение, характеристики карты.

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

Если это служба слежения за гражданами — фотография, имя, посещённые станции метро и улицы, место работы.

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

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

Чтобы преобразовать списки данных в таблицы, начните с создания таблицы для каждого типа объектов, таких как товары, продажи, клиенты и заказы. Вот пример:

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

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

• CHAR — конкретная длина текста;
• VARCHAR — текст различной длины;
• TEXT — большой объем текста;
• INT — положительное или отрицательное целое число;
• FLOAT, DOUBLE — числа с плавающей запятой;
• BLOB — двоичные данные.

Некоторые СУБД также предлагают тип данных Autonumber, который автоматически генерирует уникальный номер в каждой строке.

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

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

Атрибуты, выбранные в качестве первичных ключей, должны быть уникальными, неизменяемыми и для них не может быть задано значение NULL (они не могут быть пустыми). По этой причине номера заказов и имена пользователей являются подходящими первичными ключами, а номера телефонов или адреса — нет. Также можно использовать в качестве первичного ключа несколько полей одновременно (это называется составным ключом).

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

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