Введение в реляционную базу данных MySQL:

Концептуально-реляционная база данных - это не что иное, как поддержание требуемой взаимосвязи между несколькими таблицами с использованием некоторой концепции первичного, уникального или внешнего ключа. Любая база данных, которая практически следует этому подходу и поддерживает надлежащие отношения между всеми созданными таблицами, тогда эта база данных всегда может рассматриваться как реляционная база данных. Реляционная база данных MySQL также следует той же реляционной структуре, поэтому нет сомнений, что мой SQL также будет рассматриваться как серверная реляционная база данных, тогда как термин «отношение» не упоминался в документах MySQL или нет. Базовая база данных, которая не имеет понятия реляционной базы данных, каждая таблица содержит много данных, включая транзакционные и основные, понимание логической привязки этих данных будет очень трудным без знания правильной бизнес-логики. Реляционные базы данных обеспечивают такой подход.

Система управления отношениями реляционной базы данных MySQL:

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

Название таблицы: инвентарь

ID (первичный ключ)ОписаниеЦенаСклад

Имя таблицы: Sales_Staff

ID (первичный ключ)имяЭл. адресконтакт

Название таблицы: счет

ID (первичный ключ)SalesStaff_ID (внешний ключ первичного ключа Sales_Staff)Inventory_ID (внешний ключ первичного ключа инвентаризации)КоличествоЦенакомментарий

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

Таким образом, здесь фактически поддерживаются отношения один ко многим, когда одни данные инвентаризации могут существовать в счете-фактуре несколько раз, а одни и те же данные торгового персонала могут существовать в счете-фактуре несколько раз. Эти отношения, помогающие разработчику беспрепятственно извлекать данные с конкретными условиями соединения, а также понимать или проектировать любую диаграмму ER, будут для них очень простыми. Здесь также следует упомянуть один ключевой момент: предположим, что любой продавец пытается продать что-то, что есть в наличии, что также обеспечивается поддержанием такого рода отношений. Поскольку всякий раз, когда какой-либо инвентарь будет добавлен в счет-фактуру, он автоматически вычитает запас из исходного инвентаря, поэтому он всегда будет предоставлять надлежащее сообщение о проверке всякий раз, когда продавец пытается создать какой-либо вид счета-фактуры для конкретного инвентаря. Если мы внимательно посмотрим на отношения этих таблиц, то у Inventory будет одно имя первичного ключа - Id, а у Sales_Staff - одно имя первичного ключа - ID, но Invoice имеет два внешних ключа, которые фактически поддерживают связь с таблицами Inventory и Sales_Staff. Это также гарантирует, что в таблицу Invoice может быть вставлено все, что фактически существует в таблице Inventory или Sales_Staff, без наличия каких-либо конкретных данных невозможно сделать одну запись в таблице Invoice. Поскольку таблица Invoice имеет одну конкретную взаимосвязь внешнего ключа с обеими этими таблицами, то все, что существует только в этих таблицах, может сделать запись в таблице Invoice. Так что это всегда помогает разработчику в случае неправильной вставки без сохранения этих данных в дочерних таблицах.

Руководство по установке и загрузке My SQL Relational Database:

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

1. Загрузите реляционную базу данных MySQL по ссылке ниже:

  • http://downloads.mysql.com/docs/sakila-db.tar.gz

2. Выполнение приведенного ниже скрипта для распаковки архивного пакета:

  • tar –xzf xxxx-db.tar.gz

3. После распаковки он создаст 3 директории, как показано ниже:

  • Xxxx / Sakila-db.sql
  • Sakila-schema.sql
  • Sakila.mwb

4. Теперь запустите базовую команду MySQL:

  • Mysql –p (пароль)

5. Теперь просто следуйте инструкциям, упомянутым в sakila-db.sql и sakila-schema.sql.

6. Если все инструкции выполняются правильно, то будет создана одна новая база данных с именем «sakila», которая будет автоматически отображаться в списке реляционных баз данных MySQL.

Рекомендуемые статьи

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

  1. RDBMS Interview Вопросы и ответы
  2. Самые большие различия между MySQL и NoSQL
  3. Использование шпаргалки MySQL
  4. Вопросы интервью с СУБД

Категория:

Инструменты веб-разработки