belovorus.ru

Блог о телекоммуникациях

Популярный блог - помощник для работы за компьютером и в сети Интернет

 

 

Категории

 

Новости

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

Где сделать анализ воды в Москве
Как-то никогда не задавалась вопросом, где можно сделать анализ питьевой воды в Москве где сделать, пока соседка не написала, что от той воды из под крана, которую мы пьем, у нас чуть ли не хвост вырастет

Как оценить и рассчитать объем рынка: расчет на примере B2B сектора — PowerBranding.ru
Расчет объема рынка для B2B сектора имеет свои особенности и правила. Оценить объем B2B сегмента, наверное, даже проще, чем определить размер потребительского рынка, если знать, какие показатели использовать

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Написать администратору

Проектирование и нормализация базы данных. Нормальная форма.

  1. Проблемы, связанные с хранением данных
  2. нормализация
  3. Первая нормальная форма 1НФ
  4. Вторая нормальная форма 2NF
  5. Третья нормальная форма 3NF
  6. Преимущества и недостатки нормализации

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

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

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

Проблемы, связанные с хранением данных

Модель реляционной базы данных, разработанная Эдгаром Ф. Коддом и представленная в «Реляционной модели данных для крупных совместно используемых банков данных» , определяет, среди прочего, особенности и структура хорошо продуманной базы. Самый простой способ обобщить ядро ​​и обсудить потенциальные угрозы (плохой проект) на примере, представляющем этапы процесса стандартизации.

Почему у вас на самом деле много таблиц, отношений между ними. Проще и проще хранить все в одном месте - например, в одной таблице, как на листе Excel?
Давайте посмотрим на структуру таблицы, содержащей информацию о заказах и клиентах.

выберите * из #DEMPoints

Обратите внимание на (наиболее важные) проблемы, которые создаст для нас созданная таблица:
Обратите внимание на (наиболее важные) проблемы, которые создаст для нас созданная таблица:

  • одна и та же информация хранится много раз во многих строках (например, адрес клиента). Они занимают ресурсы без необходимости. Не только диск! Поскольку каждая строка содержит набор информации, эффективность хранения данных в таблице снижается (это связано с анатомией файла данных, способом записи строк). Это приводит к увеличению числа операций чтения / записи (очередь для ввода-вывода является одним из наиболее распространенных узких мест), а также к последующему выделению более крупных ресурсов ОЗУ (для дублирующейся информации).
  • Повторяющиеся данные также проблема, связанная с обновлением. Если мы хотим улучшить, например, адрес клиента, мы должны изменить все его вхождения (это может быть много записей). Что если мы забудем об одном? Какие данные будут правдой? Существует проблема целостности данных. Проблема обновления обостряется, когда одни и те же данные хранятся в нескольких таблицах. Мало того, что нужно помнить об изменении всех мест, это влияет непосредственно на время обновлений (транзакций). Вероятность взаимоблокировки увеличивается, происходит ухудшение параллельного доступа к данным. Это очень ощутимая проблема, субъективное восприятие скорости и качества работы системы пользователями.
  • Столбцы Адрес клиента и Адресат содержат коллекции значений. Это приводит к невозможности выполнения основных операций с данными - например, сводки по стоимости заказа, количеству элементов и т. Д. Кроме того, поиск таких коллекций неэффективен. Все сводится к поиску текстовых строк. Невозможно обеспечить полную целостность данных, поскольку они не контролируют их.
  • удаление записи - позиции заказа приводит к потере информации о клиенте, то есть той, которую мы не хотели бы потерять.
  • аналогично, наоборот - проблема с добавлением информации - необходимо указать информацию, которую мы, возможно, еще не знаем или которой она может вообще не быть - например, клиент, который не размещал никаких заказов.

нормализация

Все вышеперечисленные проблемы и аномалии решают соответствующие нормальные формы (постулаты Кодда). Нормальные формы высшего порядка подразумевают все более низкие. База данных нормализуется, например, к третьей нормальной форме, если встречаются 1NF - 3NF.

Нормализация - это процесс организации данных в таблицах без потерь, чтобы уменьшить объем данных, хранящихся в базе данных, и устранить потенциальные аномалии, описанные выше.

Первая нормальная форма 1НФ

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

Переключение на 1NF не может привести к потере информации, порядок элементов в наборе не имеет значения. Это правило применяется к любой стандартной форме.

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

- таблица в первой форме обычного выбора * из # Orders_1NF

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

Обратите внимание, что столбец Address не является атомарным. Все действительно зависит от определения атомарности, которое нас устраивает. Если атомная информация об адресе является для нас названием улицы с номером, то все в порядке. Иное, если бизнес-требования должны разделять эту информацию - например, система заказов для курьерской компании. Одну уличную услугу могут предоставлять несколько курьеров (например, длинная улица Петрковской в ​​Лодзи) - здесь вам обязательно нужно будет разделить эту информацию на две колонки.

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

Мы всегда используем наименьшие возможные типы, которые необходимы для удовлетворения требований дизайна. Если вы сохраняете данные, например, о дате рождения - нас интересует только дата, не более того (кроме базы данных больницы, где также интересна информация о времени рождения). В большинстве случаев тип данных даты должен быть выбран - который занимает 3 байта. Злоупотребление большими типами является распространенной ошибкой. Если выбран тип datetime - для каждой записи будет использовано 8 байтов для этого столбца. Мало, но верно?

  • хранение - разница (8-3 = 5 B) может быть умножена, например, на N миллионов экземпляров (записей) - тогда это производит впечатление.
  • Оперативная память - во время объединения таблиц вместо 3 + 3 или 6 байтов для каждой подключенной строки - будет выделено 8 + 8 = 16 B (еще 10 B, снова мы можем рассмотреть на этот раз N миллионов экземпляров)
  • увеличение сетевого трафика, загрузка сетевых карт,
  • снижение эффективности хранения строк на страницах - больше операций ввода-вывода
  • и у нас могут быть такие столбцы со злоупотреблениями в таблице.

Помните это во время процесса проектирования или нормализации таблицы, что хороший базовый дизайн начинается с основы - типов данных, описывающих объекты.

Вторая нормальная форма 2NF

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

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

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

- таблица в первой форме обычного выбора * из # Orders_1NF

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

Все эти атрибуты должны идти в новые таблицы - подходящие для объектов данного типа.
Таким образом, окончательное изображение 2NF будет состоять из 4 таблиц: Заказы, Клиенты, Детали, Коллекции и Продукты.
В результате этой операции таблица с информацией о заказе будет выглядеть так:

- таблица во второй форме нормального выбора * из # Orders_2NF

Новые таблицы будут выглядеть так:

- новая таблица, в которой хранится информация об объектах select * from # Customer_2NF

- новая таблица, в которой хранится информация об объектах select * from # Customer_2NF

- в новой таблице, хранящей информацию о деталях заказов, выберите * из # DetailsZamowien_2NF

- в новой таблице, хранящей информацию о деталях заказов, выберите * из # DetailsZamowien_2NF

- новую таблицу, в которой хранится информация о товаре, выберите * из # Products_2NF

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

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

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

ВЫБРАТЬ z. Номер заказа, к. Имя клиента, к. Адрес, к. Почтовый индекс, к. Город, п. Воеводзтво, д. Дамов Замовения, п. Наименование, д. Илоск, д. Прайс-Джедн, з. ВартЗамНетто, з. Ват, з. .ZeberBrutto FROM # Order_2NF с внутренним соединением # Customer_2NF k на z. ID Client = k. IDContact внутреннее соединение #DetailsName d2n on с. RecordNumber = d. StoreNumber внутреннее соединение # Products_2NF p на г. ProductProduct = p. Код продукта ИЛИ EDER BY 1

Третья нормальная форма 3NF

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

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

выберите номер заказа, идентификатор клиента, дату заказа, WartZamNetto, WartZamBrutto, ((WartZamBrutto / WartZamNetto - 1) * 100) в качестве [Vat%] из # Orders_3NF

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

Преимущества и недостатки нормализации

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

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

Ниже приведены некоторые важные функции, связанные со стандартизацией баз данных:

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

В дополнение к первым трем нормальным формам, представленным выше, мы можем встретить более высокие формы, хотя обычно они встречаются только в теоретических соображениях:

  • Нормальная форма Бойса-Кодда (также называемая 3.5NF)
  • четвертая нормальная форма 4NF
  • пятая нормальная форма 5NF

Проще и проще хранить все в одном месте - например, в одной таблице, как на листе Excel?
Что если мы забудем об одном?
Какие данные будут правдой?
Мало, но верно?

Перейти на начало страницы

 

Copyright @ 2003 г. Беловский центр телекоммуникаций, Кемеровский филиал

ОАО "Сибирьтелеком"

Каталог Апорт


Directrix.ru - рейтинг, каталог сайтов

Лучшие интернет магазины

Туристический форум ездок. Турция, Египет, другие страны