Набор навыков, который сделает вас веселее на вечеринках! Шаг за шагом
В последних сериях…
Всем привет! Добро пожаловать в четвертую часть серии руководств по SQL и SQL Server Studio. Есть простая цель: сделать вас знакомыми и удобными с инструментом и языком. — Почему это вообще имеет значение? Я вижу, ты спрашиваешь. Что ж, оказывается, любопытство и сторонние проекты часто являются ключевыми факторами при выборе новых проектов или даже при приеме на новую работу. Тот факт, что вы уже использовали такой важный инструмент, как SQL Server Studio, и написали несколько SQL-запросов, может и даст вам четкое преимущество.
Если вы пропустили Эпизод 1 о том, как настроить нашу среду и локальный сервер, перейдите к этой статье:
В Эпизоде 2 мы сосредоточились на создании баз данных и таблиц с помощью инструмента проектирования или путем написания запросов, а также на важности соглашения об именах и переходим к этой статье:
В Эпизоде 3 мы обсудили операции CRUD, которые дают вам исключительную возможность принимать решения о достоверности записей, а также о первичных и внешних ключах.
И не забудьте вернуться 😉.
Что ожидать?
Сегодня мы рассмотрим схемы. Таблицы можно рассматривать как строительные блоки, и вы можете быть архитектором, объединяющим все это. Мы рассмотрим различные типы схем, их плюсы и минусы, с конкретными и последующими примерами. Давайте прыгать прямо в!
Что такое схема?
Схема, от греческого слова σχῆμα (скема), означающего форму, план¹.
Итак, схема — это способ организации вещей. В нашем случае, чтобы организовать наши столы. Мы могли использовать слова "диаграмма", "структура" или "архитектура" как синонимы.
Типы схем
Мы можем сгруппировать их в три категории. Первый может заставить некоторых людей немного съежиться, но это ради демонстрации.
Схема Flat Table — простая схема
Назвать сложную плоскую таблицу, используемую для решения, «схемой», возможно, будет преувеличением. Тем не менее, если рассматривать схемуозначает форму, сложную плоскую таблицу можно рассматривать как простую схему.
Что такое «сложный плоский стол»? Это будет тот, в котором все столбцы или функции, связанные с данными, собираются в одной таблице. Представьте, что вы храните все данные HR в одной таблице:
- Имя сотрудника, рабочий и личный адрес электронной почты, рабочий и личный номер телефона, дата присоединения и ухода (если есть),
- Должность, звание, отдел,
- Зарплата, последняя работа, тенденция производительности, …
Плоская таблица, подобная упомянутой выше, имеет то преимущество, что ее легко понять и сортировать для получения быстрых результатов. Это может быть очень удобно. Но это не потому, что могло оно должно. Если вы хотя бы раз нахмурились, взглянув на вышеупомянутые столбцы, я с вами по двум причинам:
- Различные уровни конфиденциальности данных
Существуют различные уровни конфиденциальности элементов данных, упомянутых выше. Как сотрудник, информация об имени или служебном адресе электронной почты коллеги, вероятно, доступна всем в компании.
Но личная электронная почта и номер телефона? Это запрещено. То же самое должно быть верно для доступности этих данных в таблицах SQL:
- Пользователи с доступом SQL к списку сотрудников должны видеть только то, что доступно всем внутри компании,
- То, что считается более конфиденциальным, должно находиться в другом месте, в другой таблице или системе, и должно быть доступно для запросов только небольшому пулу пользователей из основного отдела кадров, отвечающего за данные о сотрудниках.
- То же самое касается показателей заработной платы и производительности, которые должны быть ограничены кем угодно, кроме команды HR Payroll.
2. Разделенная структура может обеспечить большую ясность, более быстрые запросы и меньшие таблицы.
Этот, казалось бы, простой стол может быстро превратиться в мастодонта. Также существует риск избыточности, поскольку мы используем плоскую таблицу вместо реляционной базы данных. Если бы нам нужно было отслеживать тенденции производительности с течением времени, мы бы закончили с несколькими строками для Максима для каждого нового обзора производительности, а остальные были бы избыточными повторениями данных по рангу и зарплате.
Что касается производительности, есть также некоторые проблемы:
- Необходимо прочитать больше данных, поэтому запросы могут быть медленными,
- Размеры таблиц быстро растут, что делает их неоптимальными для работы из-за повторяющихся данных.
Мы обсудили плюсы и минусы плоской структуры стола. Поскольку все столбцы были частью одной таблицы, можно сказать, что это централизованная структура. Давайте теперь посмотрим на децентрализованные или нормализованные схемы.
Нормализованный путь
Всякий раз, когда структура данных разделена на разные таблицы, мы говорим, что схема нормализована. Если бы мы визуализировали нашу вышеупомянутую плоскую таблицу, мы могли бы представить ее аналогичным образом:
В этой реляционной схеме каждый сотрудник подключен к:
- Департаменты,
- Заработная плата,
- Личная контактная информация сотрудника,
- Активы с активами, связанными с типами активов
Эта схема позволяет нам разделять нашу информацию по разным таблицам, кроме того, это может упростить подход к защите данных, поскольку нам нужно заботиться об уровне таблицы или базы данных, а не уровне строки. Однако проблема с нормализованной базой данных заключается в том, что для получения информации из данных потребуется множество JOINS.
Нормализация простой таблицы следует определенным шагам.
- UNF: это ненормализованная форма, как обычная таблица.
- 1NF: чтобы удовлетворить этому требованию, каждый столбец должен содержать только одно значение и быть уникальным. Сотрудник с двумя активами изначально имел бы
#PLAIN TABLE Employee_Name Assets 'Maxime' 'Laptop, Monitor'
Чтобы удовлетворить 1NF, его можно разделить на два столбца и стать Активом_1, Активом_2.
#Employee PLAIN TABLE Employee_Name Asset_1 Asset_2 (... other columns ...) 'Maxime' 'Laptop' 'Monitor' (... other rows...)
Но что произойдет, если у сотрудника три актива? Запись этого сотрудника не подходит, потому что у нас есть только два столбца активов. Точно так же для репозитория книг представьте, что у нас есть только две категории книг. Книга с 4 категориями, такими как «жизнь, здоровье, благополучие, самопомощь», не влезла бы.
Лучшим подходом было бы создание новой таблицы только для активов. Как обсуждалось ранее в части 3 на примере взаимосвязи между таблицами «Сотрудник» и «Отдел», это стало возможным с помощью первичного и внешнего ключей.
- 2NF: чтобы перейти к шагу 2NF, нам нужно сначала выполнить 1NF. На этом этапе мы также хотим удалить дубликаты. Первичный и внешний ключи пригодятся, давайте посмотрим, почему. Как упоминалось в нашей воображаемой простой таблице «Сотрудники», у нас был список исторических обзоров производительности сотрудников.
#Employee PLAIN TABLE Employee_Name Performance_Date Performance_Rating 'Maxime' 'June 2020' 5 'Maxime' 'December 2020' 4 'Jane' 'June 2020' 5 'Jane' 'December 2020' 5
Вместо этого мы переместим дату исполнения и рейтинг в другую таблицу. Это превратит нашу таблицу сотрудников в:
#Employee table
Employee_ID (PK) Employee_Name (... other columns ...)
1 'Maxime'
2 'Jane'
(... other rows...)
И наша таблица производительности:
#Performance Perf_ID Performance_Date Performance_Rating Employee_ID (FK) 1 'June 2020' 5 1 2 'June 2020' 5 2 3 'December 2020' 4 1 4 'December 2020' 5 2
Наш Employee_ID — это первичный ключ (PK) в таблице Employee и внешний ключ (FK) в нашей таблице Performance. Это позволяет нам узнать производительность каждого сотрудника. Но нет ли дублирования в таблице производительности? Вы правы, мы могли бы также представить его нормализацию и иметь Performance_Rating для сбора рейтингов и Performance_Cycles для сбора дат.
- 3NF: нам нужно следовать 2NF, и мы хотим решить все транзитивные функциональные зависимости. Что это означает конкретно? Для этого шага нормализации и следующего мы будем использовать другой пример, чтобы передать эти понятия.
Представьте себе эту таблицу:
У нас есть транзитивные функциональные зависимости, потому что национальность автора зависит от автора, который, в свою очередь, зависит от книги [название]. У нас есть еще один с [названием жанра], который зависит от [идентификатора жанра], который, в свою очередь, зависит от книги [название].
Мы хотим, чтобы [национальность автора] и [название жанра] были в своих собственных таблицах.
#Author table Author Author Nationality Chad Russel American EF Codd British
И таблица [Жанр]:
#Genre table
Genre ID Genre Name
1 Tutorial
2 Popular Science
Это с шагами нормализации? Нет. Но чаще всего нормализация происходит до 3НФ. То, что мы рассмотрели выше, уже является сильным началом для нормализации и организации данных и ограничения аномалий. Дополнительные ресурсы см. в следующем разделе.
Идти дальше
- BCNF: это означает нормальную форму Бойса-Кодда и часто упоминается как 3.5NF, поскольку она фокусируется на аномалиях, не охватываемых 3NF. Бойсу и Кодду приписывают его изобретение. Бойс стал соавтором SQL², а Кодд изобрел реляционную модель для управления базами данных³ и стоит за этапами нормализации, которые мы обсуждали.
BCNF определяется⁴ как:
Реляционная схема R находится в НФБК тогда и только тогда, когда для каждой из ее зависимостей X → Y выполняется хотя бы одно из следующих условий:
•X → Y — тривиальная функциональная зависимость (Y ⊆ X), (Y — подмножество X)
•X — суперключ для схемы R.
Большинство отношений, покрываемых 3NF, находятся в BCNF, но не все. Вот пример.
- 4NF, 5NF и 6NF эта ссылка или эта ссылка может помочь
Заключительные слова
Это все на данный момент! В этой статье основное внимание уделялось теоретической концепции схем и нормализации, а не использованию SQL Server. Тем не менее, благодаря поддержке из предыдущих статей, теперь вы можете попытаться нормализовать таблицу, выполнив шаги по нормализации.
Спасибо за чтение, дайте мне знать, что вы думаете, или если есть тема, которую я должен осветить. До скорого!
Удачного кодирования!
Спасибо за чтение! Понравилась эта история? Присоединиться к Medium, чтобы получить полный доступ ко всем моим историям.
Продолжите путешествие с Эпизодом 5!
Узнайте, как писать хранимые процедуры SQL и планировать задания с помощью агента заданий SQL, из 5-го эпизода.
Или выберите другой выпуск по вашему выбору
В эпизоде 6 мы представляем пакеты служб SSIS для ETL и анализируем возможности импорта и экспорта данных между двумя базами данных, а также между базой данных и Excel. Часть 6. Введение в пакеты SSIS
В седьмом эпизоде мы подключаем SQL Studio к PowerBI и создаем первые визуальные элементы. Часть 7. Подключение к PowerBI и первые визуальные элементы
Ссылки
- Схема — Википедия, https://en.wikipedia.org/wiki/Schema#:~:text=The%20word%20schema%20comes%20from,are%20used%20as%20plural%20forms.
- Бойс — Википедия, https://en.wikipedia.org/wiki/Raymond_F._Boyce
- Кодд — Википедия, https://en.wikipedia.org/wiki/Edgar_F._Codd
- Зильбершац, Авраам (2006). Концепции системы баз данных (6-е изд.). Макгроу-Хилл. стр. 333. ISBN 978–0–07–352332–3.
