Продолжение. Предыдущие части: 1-3, 4-6, 7-9
10. Нормализация баз данных
Указания для правильного проектирования реляционных баз данных изложены в реляционной модели данных. Они собраны в 5 групп, которые называются нормальными формами. Первая нормальная форма представляет самый низкий уровень нормализации баз данных. Пятый уровень представляет высший уровень нормализации.
Нормальные формы – это рекомендации по проектированию баз данных. Вы не обязаны придерживаться всех пяти нормальных форм при проектировании баз данных.
Тем не менее, рекомендуется нормализовать базу данных в некоторой степени потому, что этот процесс имеет ряд существенных преимуществ с точки зрения эффективности и удобства обращения с вашей базой данных.
- В нормализованной структуре базы данных вы можете производить сложные выборки данных относительно простыми SQL-запросами.
- Целостность данных. Нормализованная база данных позволяет надежно хранить данные.
- Нормализация предотвращает появление избыточности хранимых данных. Данные всегда хранятся только в одном месте, что делает легким процесс вставки, обновления и удаления данных. Есть исключение из этого правила. Ключи, сами по себе, хранятся в нескольких местах потому, что они копируются как внешние ключи в другие таблицы.
- Масштабируемость – это возможность системы справляться с будущим ростом. Для базы данных это значит, что она должна быть способна работать быстро, когда число пользователей и объемы данных возрастают. Масштабируемость – это очень важная характеристика любой модели базы данных и для РСУБД.
Вот некоторые из основных пунктов, которые связаны с нормализацией баз данных:
- Упорядочивание данных в логические группы или наборы.
- Нахождение связей между наборами данных. Вы уже видели примеры связей один-ко-многим и многие-ко-многим.
- Минимизация избыточности данных.
Очень малое количество баз данных следуют всем пяти нормальным формам, предоставленным в реляционной модели данных. Обычно базы данных нормализуются до второй или третьей нормальной формы. Четвертая и пятая формы используются редко. Поэтому я ограничусь тем, чтобы рассказать вам лишь о первых трех.
11. Первая нормальная форма (1НФ)
Первая нормальная форма гласит, что таблица базы данных – это представление сущности вашей системы, которую вы создаете. Примеры сущностей: заказы, клиенты, заказ билетов, отель, товар и т.д. Каждая запись в базе данных представляет один экземпляр сущности. Например, в таблице клиентов каждая запись представляет одного клиента.
Первичный ключ
Правило: каждая таблица имеет первичный ключ, состоящий из наименьшего возможного количества полей. Как вы знаете, первичный ключ может состоять из нескольких полей. Вы, к примеру, можете выбрать имя и фамилию в качестве первичного ключа (и надеяться, что эта комбинация будет уникальной всегда).
Будет намного более хорошим выбором номер соц. Страхования в качестве первичного ключа, т.к. это единственное поле, которое уникальным образом идентифицирует человека.
Еще лучше, когда нет очевидного кандидата на звание первичного ключа, создайте суррогатный первичный ключ в виде числового автоинкрементного поля.
Атомарность
Правило: поля не имеют дубликатов в каждой записи и каждое поле содержит только одно значение. Возьмем, например, сайт коллекционеров автомобилей, на котором каждый коллекционер может зарегистрировать его автомобили. Таблица ниже хранит информацию о зарегистрированных автомобилях. 
Горизонтальное дублирование данных – плохая практика. С таким вариантом проектирования вы можете сохранить только пять автомобилей и если у вас их менее 5, то вы тратите впустую свободное место в базе данных на хранение пустых ячеек. Другим примером плохой практики при проектировании является хранение множественных значений в ячейке. 
Множественные значения в одной ячейке. Верным решением в данном случае будет выделение автомобилей в отдельную таблицу и использование внешнего ключа, который ссылается на эту таблицу.
Порядок записей не должен иметь значение
Правило: порядок записей таблицы не должен иметь значения. Вы можете быть склонны использовать порядок записей в таблице клиентов для определения того, какой из клиентов зарегистрировался первым.
Для этих целей вам лучше создать поля даты и времени регистрации клиентов. Порядок записей будет неизбежно меняться, когда клиенты будут удаляться, изменяться или добавляться. Вот почему вам никогда не следует полагаться на порядок записей в таблице.
В следующей части рассмотрим вторую нормальную форму (2НФ).
12. Вторая нормальная форма
Для того, чтобы база данных была нормализована согласно второй нормальной форме, она должна быть нормализована согласно первой нормальной форме. Вторая нормальная форма связана с избыточностью данных.
Избыточность данных
Правило: поля с не первичным ключом не должны быть зависимы от первичного ключа. Может звучать немного заумно. А означает это то, что вы должны хранить в таблице только данные, которые напрямую связаны с ней и не имеют отношения к другой сущности.
Следование второй нормальной форме – это вопрос нахождения данных, которые часто дублируются в записях таблицы и которые могут принадлежать другой сущности. 
Дублирование данных среди записей в поле store. Таблица выше может принадлежать компании, которая продает автомобили и имеет несколько магазинов в Нидерландах.
Если посмотрите на эту таблицу, то вы увидите множественные примеры дублирования данных среди записей. Поле brand могло бы быть выделено в отдельную таблицу. Также, как и поле type (модель), которое также могло бы быть выделено в отдельную таблицу, которая бы имела связь многие-к-одному с таблицей brand потому, что у бренда могут быть разные модели.
Колонка store содержит наименование магазина, в котором в настоящее время находится машина. Store – это очевидный пример избыточности данных и хороший кандидат для отдельной сущности, которая должна быть связана с таблицей автомобилей связью по внешнему ключу.
Ниже пример того, как бы вы моги смоделировать базу данных для автомобилей, избегая избыточности данных. 
В примере выше таблица car имеет внешний ключ – ссылку на таблицы type и store. Столбец brand исчез потому, что на бренд есть неявная ссылка через таблицу type. Когда есть ссылка на type, есть ссылка и на brand, т.к. type принадлежит brand.
Избыточность данных была существенным образом устранена из нашей модели базы данных. Если вы достаточно придирчивы, то вы, возможно, еще не удовлетворены этим решением.
А как насчет поля country_of_origin в таблице brand? Пока дубликатов нет потому, что есть только четыре бренда из разных стран.
Внимательный разработчик базы данных должен выделить названия стран в отдельную таблицу country.
И даже сейчас вы не должны быть удовлетворены результатом потому, что вы также могли бы выделить поле color в отдельную таблицу.
Насколько строго вы подходите к созданию ваших таблиц – решать вам и зависит от конкретной ситуации. Если вы планируете хранить огромное количество единиц автомобилей в системе и вы хотите иметь возможность производить поиск по цвету (color), то было бы мудрым решением выделить цвета в отдельную таблицу так, чтобы они не дублировались.
Существует другой случай, когда вы можете захотеть выделить цвета в отдельную таблицу. Если вы хотите позволить работникам компании вносить данные о новых автомобилях вы захотите, чтобы они имели возможно выбирать цвет машины из заранее заданного списка.
В этом случае вы захотите хранить все возможные цвета в вашей базе данных. Даже если еще нет машин с таким цветом, вы захотите, чтобы эти цвета присутствовали в базе данных, чтобы работники могли их выбирать.
Это определенно тот случай, когда вам нужно выделить цвета в отдельную таблицу.
13. Третья нормальная форма
Третья нормальная форма связана с транзитивными зависимостями. Транзитивные зависимости между полями базы данных существует тогда, когда значения не ключевых полей зависят от значений других не ключевых полей. Чтобы база данных была в третьей нормальной форме, она должна быть во второй нормальной форме.
Транзитивные зависимости
Правило: не может быть транзитивных зависимостей между полями в таблице. Таблица клиентов (мои клиенты – игроки немецкой и французской футбольной команды) ниже содержит транзитивные зависимости. 
В этой таблице не все поля зависят исключительно от первичного ключа. Существует отдельная связь между полем postal_code и полями города (city) и провинции (province). В Нидерландах оба значение: город и провинция – определяются почтовым кодом, индексом. Таким образом, нет необходимости хранить город и провинцию в клиентской таблице. Если вы знаете почтовый код, то вы уже знаете город и провинцию. Такая транзитивной зависимости следует избегать, если вы хотите, чтобы ваша модель базы данных была в третьей нормальной форме. В данном случае устранение транзитивной зависимости из таблицы может быть достигнуто путем удаления полей города и провинции из таблицы и хранение их в отдельной таблице, содержащей почтовый код (первичный ключ), имя провинции и имя города. Получение комбинации почтовый код-город-провинция для целой страны может быть весьма нетривиальным занятием. Вот почему такие таблицы зачастую продаются. Другим примером для применения третьей нормальной формы может служить (слишком) простой пример таблицы заказов интернет-магазина ниже. 
НДС (value added tax) – это процент, который добавляется к цене продукта (19% в данной таблице). Это означает, что значение total_ex_vat может быть вычислено из значения total_inc_vat и vice versa. Вы должны хранить в таблице одно из этих значений, но не оба сразу. Вы должны возложить задачу вычисления total_inc_vat из total_ex_vat или наоборот на программу, которая использует базу данных. Третья нормальная форма гласит, что вы не должны хранить данные в таблице, которые могут быть получены из других (не ключевых) полей таблицы. Особенно в примере с таблицей клиентов следование третьей нормальной форме требует либо большого объема работы, либо приобретения коммерческой версии данных для такой таблицы.
Третья нормальная форма не всегда используется при проектировании баз данных. Когда разрабатываете базу данных вы всегда должны сравнивать преимущества от более высокой нормальной формы в сравнении с объемом работ, которые требуются для применения третьей нормальной формы и поддержания данных в таком состоянии. В случае с клиентской таблицей лично я бы предпочел не нормализовать таблицу до третьей нормальной формы. В последнем примере с НДС я бы использовал третью нормальную форму. Хранение данных, воспроизводимых из существующих, обычно плохая идея.
Источник: https://habr.com/post/193756/
Нормализация базы данных и ее формы
Материал этой статьи напрямую не относиться к изучению языка SQL, так как имеет отношение к проектированию баз данных (БД), но для общего понимания взаимосвязи хранимой в системе информации она будет полезна.
По поводу того, как должна быть спроектирована база нет 100% решения, потому что конкретный вариант может удовлетворять либо не удовлетворять различным бизнес-процессам и целям. Но не принимать во внимание элементарные правила нельзя, так как их соблюдение сохранит много времени, нервов и денег при работе с данными.
Нормализация баз данных заключается в приведении структуры хранения данных к нормальным формам (NF). Всего таких форм существует 8, но часто достаточным является соблюдение первых трех. Рассмотрим их более подробно на примере учебной базы данных. Примеры будут строится по принципу «что было бы, если было иначе, чем сейчас».
Первая нормальная форма
Основным правилом первой формы является необходимость неделимости значения в каждом поле (столбце) строки – атомарность значений.
Рассмотрим таблицы сотрудников и телефонных линий.
- Чтобы избавиться от связывающей таблицы «Сотрудники_Линии», мы могли бы записать идентификаторы сотрудников для каждой линии в виде перечня в дополнительном столбце:
Но подобная структура не является надежной. Представьте, что Вам необходимо поменять некоторым сотрудникам подключенные линии. Потребуется осуществить разбор составного поля, чтобы определить наличие id сотрудника в каждой записи линий, затем скорректировать перечень. Получается слишком сложный и долгий процесс для такой простой операции.
Организации структуры таблиц с применением дополнительной связывающей избавляет от подобных проблем.
Помимо атомарности к первой нормальной форме относятся следующие правила:
- Строки таблиц не должны зависеть друг от друга, т.е. первая запись не должна влиять на вторую и наоборот, вторая на третью и т.д. Размещение записей в таблице не имеет никакого значения.
- Аналогичная ситуация со столбцами записей. Их порядок не должен влиять на понимание информации.
- Каждая строка должна быть уникальна, поэтому для нее определяется первичный ключ, состоящий из одного либо нескольких полей (составной ключ). Первичный ключ не может повторяться в пределах таблицы и служит идентификатором записи.
Вторая нормальная форма
Условием этой формы является отсутствие зависимости неключевых полей от части составного ключа.
Так как составной ключ в учебной базе наблюдается только в таблице «Сотрудники_Линии», то рассмотрим пример на ней.
На представленной диаграмме столбцы описания и приоритета зависят от столбца «Линия», входящего в составной ключ. Это значит, что для каждой линии, подключенной разным сотрудникам, потребуется повторно указывать описание и приоритетность. Подобная структура приводит к избыточности данных.
Также велика вероятность возникновения противоречивой информации. Изменяя приоритет или описание для линии, можно по ошибке оставить некоторые строки не обработанными. В таком случае, для одного и того же идентификатора линии значения зависимых полей будут различными.
Если соблюдены правила первой нормальной формы, то создание таблицы «Линии» и перенос в нее зависимых столбцов удовлетворяет второй нормальной форме.
Третья нормальная форма
3NF схожа по логике с 2NF, но с некоторым отличием. Если 2 форма ликвидирует зависимости неключевых полей от части ключа, то третья нормальная форма исключает зависимость неключевых полей от других неключевых полей.
На приведенном примере таблицы сотрудников видно, что столбец «Супервайзер» имеет зависимость от столбца «Группа», а это значит, что при изменении значения поля группы, потребуется изменить значение поля супервайзера.
Все риски, которые были рассмотрены для 2NF, так же относятся к 3NF и устраняются переносом зависимых полей в отдельную таблицу.
Денормализация базы данных
Теория нормальных форм не всегда применима на практике. Например, неатомарные значения не всегда являются «злом», а иногда наоборот. Связано это с необходимостью дополнительного объединения (следовательно, затрат производительности системы) при выполнении запросов, особенно когда производится обработка большого массива информации.
Для баз данных, предназначенных для аналитики, часто выполняют денормализацию, чтобы укорить выполнение запросов.
Новые статьи:
Если материалы office-menu.ru Вам помогли, то поддержите, пожалуйста, проект, чтобы мы могли развивать его дальше.
У Вас недостаточно прав для комментирования.
Источник: http://office-menu.ru/uroki-sql/51-normalizatsiya-bazy-dannykh
Нормализация базы данных
При построении баз данных необходимо следовать определённым правилам. Эти правила получили название нормализации баз данных. Нормализация базы данных является не обязательной, но эти правила существенно упростят работу по составлению запросов и способствуют улучшению масштабируемости.
Нормализация базы данных – это рекомендации по проектированию.
Преимущества нормализованной базы данных:
- Возможность существенно упростить выборки. Получение данных из базы относительно простыми запросами.
- Целостность данных. Избежание потерь или искажения информации в базе данных.
- Отсутствие избыточности. Данные в таблице не дублируются, что существенно снижает её размер.
- Благоприятные предпосылки к росту базы.
Как привести базу данных к нормальной форме?
Для приведения базы к нормальной форме необходимо выполнить следующие действия:
- Постараться объединить данные в группы.
- Найти логические связи между этими группами данных. Для установки связей связываемые поля должны быть одного типа и таблица формата InnoDB.
Существует 3 нормальные формы базы данных:
- Первая нормальная форма
В одной ячейке одно значение. Исключение тип данных SET
Таблица представляет сущность которая в ней размещена (например клиенты, заказы и т.д.) Причём в каждой таблице имеется уникальное поле (первичный ключ) например id и каждая таблица состоит из наименьшего количества полей.
Пример №1:
id name languages 1 Иван Java, C++, PHP 2 Пётр PHP, JavaScript 3 Михаил C#, JavaScript В примере №1. Представлена не удачная структура таблицы, где в поле languages указано перечисление.
Пример №2:
id name languages1 languages2 languages3 1 Иван Java C++ PHP 2 Пётр PHP JavaScript NULL 3 Михаил C# JavaScript NULL
В примере №2 тоже не верная структура таблицы для поля languages.
Правильная структура таблиц для решения данной задачи:
Пример №3:Таблица пользователей
id name languages_id 1 Иван Java, C++, PHP 2 Пётр PHP, JavaScript 3 Михаил C#, JavaScript Таблица языков программирования
id language 1 Java 2 PHP 3 C# 4 JavaScript 5 Java Таблица связей между пользователями и языками программирования
id language_id user_id 1 2 1 2 1 1 3 5 1 4 1 2 - Вторая нормальная форма
Для второй нормальной формы требуется первая нормальная форма.Поля с не первичным ключом не должны быть зависимы от первичного ключа.
Пример №4:
id make model 1 bmw X5 2 bmw X6 3 audi A4 4 audi Q5 5 toyota corolla В примере №4 мы видим дублирование некоторых марок автомобилей (Данные избыточны). Требуется сделать разделение на несколько таблиц как в примере №3. На первый взгляд создание новых таблиц кажется более затратным чем реализация в примере №4, но это только до тех пор когда таблица состоит всего из нескольких строк.
Правильная структура таблиц для решения данной задачи:
- Третья нормальная форма
Требуется вторая нормальная форма.- Согласно третьей нормальной форме данные не должны храниться в таблице, которые могут быть получены из не ключевых полей.
- Пример №5:
- Таблица цен и цен с НДС
id price price_nds 1 1100 1243 2 950 1074 Так как цену с НДС можно получить из поля price, то данную задачу нужно переложить на язык программирования.
Author
«Всегда пишите код так, будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.»Martin Golding
Источник: https://liblessons.ru/programming/article-in-mysql/normalize_db/
Нормализация бд
Нормализация
выполняется с помощью приведения к
«Нормальным формам»:
- I НФ (каждое поле неделимо и не содержало повторяющихся групп);
- II НФ (все поля зависят от первичного ключа);
- III НФ (удаление всех неключевых полей, которые зависят от других неключевых полей).
Предназначениенормализации
─ устранение избыточной информации.
Недостатки:
- большое количество таблиц;
- увеличение времени на поиск в подчиненных таблицах.
Рассмотрим
СУБД
Microsoft Access
Ms Access
Приложение MS Access
– система управления реляционными
базами данных, предназначенная для
работы на автономном ПК или в локальной
вычислительной сети под управлением
Microsoft Windows.
Средствами Access
можно проводить следующие операции:
-
Проектирование базовых объектов (двумерных таблиц), с разными типами данных.
-
Установление связей между таблицами, с поддержкой целостности данных, каскадного обновления полей и каскадного удаления записей.
-
Ввод, хранение, сортировка, модификация и выборка данных из таблиц.
-
Создание, модификация и использование производных объектов (форм, запросов и отчетов).
Способы создания
основных объектов:
- ручные (в режиме конструктора);
- автоматизированные (в режиме мастера);
- автоматические (ускоренная разработка простейших объектов).
Соотношения между
этими средствами: ручные средства
являются наиболее трудоемкими, но
обеспечивают максимальную гибкость;
автоматизированные и автоматические
средства являются наиболее производительными,
но и наименее гибкими.
-
При разработке таблиц и запросов рекомендуется использовать ручные средства – работать в режиме Конструктора. Использование мастера ускоряет работу, но не способствует освоению понятий и методов.
-
При разработке учебных форм и отчетов наоборот лучше пользоваться автоматизированными средствами, предоставляемые мастерам. Это связано с тем, что для данных объектов большую роль играет внешний вид. Дизайн этих объектов весьма трудоемок, поэтому его лучше поручить программе, а учащемуся сосредоточиться на содержательной части работы.
-
Разработкой макросов и модулей должны заниматься профессиональные разработчики баз данных.
Объекты субд Access
Таблицы
─ основной объект базы данных. Во-первых,
в таблицах хранятся все данные, имеющиеся
в базе, а во-вторых, таблицы хранят и
структуру базы данных (поля, их типы и
свойства).
Запросы
─ средство отбора данных из одной или
нескольких таблиц по определённому
пользователем условию.
Формы
─ средства для ввода новых данных или
просмотра уже имеющихся (своего рода
бланк, который удобно заполнять для
ввода данных в базу). Программа связывает
введённые в форму данные с таблицей и
хранит их в таблице.
Отчеты
─ средство для выдачи результатов на
печатающее устройство.
Макросы
─ макрокоманды. Позволяют упростить
длинные последовательности утомительных
действий. Фактически, это средство для
автоматизации работы с БД.
Модули
─ это программы, написанные на языке
программирования Visual Basic for Applications (VBA).
Рассмотрим некоторые
объекты СУБД Access более подробно
Источник: https://studfile.net/preview/3853602/page:3/
Создаем таблицы и проводим нормализацию
- Открываем Access, создаем новую пустую базу данных.
- После этого выбираем команду «Создать таблицу»
- Начинаем с таблицы «Физические лица» .
| Наименование данных | Тип данных | Примечание | Тип данных Access |
| Серия паспорта | Строка | Серия паспорта состоит из двух букв | Текстовый, Длина поля — 2, Обязательное — Да Пустые строки — Нет Индексированное — Да, допускаются совпадения |
| Номер паспорта | Число | Номер паспорта — целое число | Числовой, Длинное целое, Число десятичных знаков — 0, Маска ввода — 000000, Обязательное — Да, Индексированное — Да, допускаются совпадения |
| ИНН | Число | Обязательно для идентификации, число. Внимание! Для реальной базы данных так делать нельзя, потому что человек может отказаться от получения ИНН по религиозным соображениям и ИНН у него может отсутствовать. Мы же для простоты считаем, что у каждого человека есть свой уникальный ИНН | Числовой, Длинное целое, Число десятичных знаков — 0, Маска ввода — 0000000000 Обязательное — Да, Индексированное — Да, совпадения не допускаются, Ключевое |
| Адрес прописки | Строка | Адрес прописки будет нужен для оформления юридических действий | Текстовое, Размер поля — 255 |
| Адрес проживания | Строка | Этот адрес будет нужен для связи с клиентом, направления ему писем | Текстовое, Размер поля — 255 |
| Контактный телефон | Строка | Потребуется для быстрой связи с клиентом. Тип данных — могло быть и число, но для простоты учебного примера — пусть будет строка | Текстовое, Размер поля — 16 |
Перед созданием таблицы «Юридические лица» необходимо создать служебную таблицу «Формы собственности»
| Наименование | Тип данных | Комментарий | Тип данных Access |
| ID | Этот идентификатор необходим для дальнейшего создания связи с таблицей «Юридические лица» | Тип данных — Счетчик, Длинное целое, Последовательный, Индексированное — Да, совпадения не допускаются | |
| Форма собственности | Это — текстовое название формы собственности | Текстовое, Размер поля — 255 |
Создаем таблицу «Юридические лица»
| Наименование | Тип данных | Комментарий | Тип данных Access |
| Наименование юр.лица | Строка | Наименование — обязательный параметр, однако, встречаются организации с одинаковыми названиями | Текстовое, Размер поля — 255 |
| Код | Число | Код организации однозначно ее идентифицирует | Числовой, Длинное целое, Число десятичных знаков — 0, Обязательное поле — Да, Индексированное — Да, совпадения не допускаются, Ключевое |
| Форма собственности | Виды форм собственности определяются законодательством. Но справочник форм собственности у нас уже создан и вместо указания самой формы собственности мы будем использовать ссылку на нее. Поэтому укажем тип поля — как числовое, длинное целое. | Числовой, Длинное целое, Обязательное — Да, Индексированное — Да, совпадения допускаются | |
| Юридический адрес | Строка | Адрес, по которому зарегистрировано юр. лицо | Текстовое, Размер поля — 255 |
| Адрес для переписки | Строка | Адрес, по которому следует направлять почтовую корреспонденцию. Часто, это — разные адреса | Текстовое, Размер поля — 255 |
| Телефон | Строка | Контактный телефон приемной, можно задать числом, но мы зададим строкой для простоты примера | Текстовое, Размер поля — 16 |
| Директор | Поскольку таблица физических лиц уже есть, то мы вместо указания директора, будем хранить ссылку на таблицу физических лиц. Поэтому укажем тип поля — как числовое, длинное целое. | Числовой, Длинное целое, Обязательное — Да, Индексированное — Да, совпадения допускаются | |
| Главный бухгалтер | Поскольку таблица физических лиц уже есть, то мы вместо указания директора, будем хранить ссылку на таблицу физических лиц. Поэтому укажем тип поля — как числовое, длинное целое. | Числовой, Длинное целое, Обязательное — Нет, Индексированное — Да, совпадения допускаются |
Создаем таблицу «Условия депозитов»
| Наименование данных | Тип данных | Комментарий | Тип данных Access |
| Код | По данному полю мы будем идентифицировать тип депозита | Счетчик, Длинное целое, Новые значения — последовательные, Индексируемое — Да, совпадения не допускаются | |
| Срок начала действия условий депозита | Дата | Дата начала срока действия условий нужна для того, чтобы не иметь возможности открыть депозит раньше времени | Дата/Время Обязательное — Да |
| Срок окончания действия условий депозита | Дата | Возможна ситуация, когда депозиты по старым условиям еще лежат в банке, но новые вклады на данных условиях уже не принимаются. Значение окончания действия также может отсутствовать, если предложение действует в данный момент | Дата/Время Обязательное — Нет |
| Условия действительны для физических лиц | Логический | Предполагается информация да/нет | Логический Формат поля — Да/Нет |
| Условия действительны для юридических лиц | Логический | Предполагается информация да/нет | Логический Формат поля — Да/Нет |
| Минимальная сумма депозита | Число | Денежный | |
| Минимальный срок размещения (дней) | Число | Без указания срока размещения договор депозита смысла не имеет | Целое, Значение по умолчанию — 30, Обязательное — Да |
| Процентная ставка | Число | Одинарное с плавающей точкой | |
| Условия выплаты процентов | Перечисление | Можно было бы создать отдельный справочник с условиями видов начисления процентов, но для простоты примера мы принимаем следующее: 0 — ежемесячное начисление по концу месяца на отдельный счет 1 — начисление по концу месяца на тот же самый счет 2 — начисление процентов в конце срока на тот же самый счет | Целое, Значение по умолчанию — 0, Обязательное — Да |
| Возможно ли пополнение депозита | Логический | Логический Формат поля — Да/Нет | |
| Допускается ли досрочное снятие | Логический | Досрочное снятие — это, фактически, разрыв условий договора, поэтому, как правило, при выплате процентов на вклад начисляются проценты по ставке, иной, чем изначально оговоренная | Логический Формат поля — Да/Нет |
| Процентная ставка при досрочном снятии | Число | Одинарное с плавающей точкой |
Создаем таблицу «Договоры»
| Наименование | Тип данных | Примечание | Тип данных Access |
| Код | Для идентификации можно, конечно, использовать и номер договора. Но, поскольку, строка не удобна для создания связей между таблицами и, потенциально, будет замедлять быстродействие, создание дополнительного поля оправдано | Счетчик, Длинное целое, Новые значения — последовательные, Индексированное — Да, совпадения не допускаются | |
| Дата заключения | Дата | Дата/Время, Значение по умолчанию =Date(), Обязательное — Да | |
| Номер | Строка | Договор может быть пронумерован, например, как 1/3-55, поэтому тип данных — строка | Текстовый, Размер поля — 32 |
| Дата окончания | Дата | Считаем, что все договоры имеют дату окончания и не пролонгируются | Дата/Время |
| Договор с юр или физ лицом? | Логический | Далее у нас две ссылки, и лишь одна из них будет задействована. Поэтому данное поле, фактически, является переключателем, с кем у нас заключен договор и на какую таблицу искать ссылку (физ или юр) | |
| Договор с юр лицом | Ссылка на юридическое лицо | Числовой, Длинное целое, Индексированное — Да, допускаются совпадения | |
| Договор с физ лицом | Ссылка на физическое лицо | Числовой, Длинное целое, Индексированное — Да, допускаются совпадения |
Создаем таблицу «Счета»
| Наименование | Тип данных | Примечание | Тип данных Access |
| Группа счета | Число | Согласно утвержденному плану счетов банков в Украине это должна быть цифра «26» всегда. Поэтому редактирование поля мы не предумотрим | Тип данных — Целое, Значение по умолчанию — 26 |
| Подгруппа счета | Число | «10», если это — краткосрочный депозит юр. лица «15», если это — долгосрочный депозит юр. лица «30», если это — краткосрочный депозит физ. лица «35», если это — долгосрочный депозит физ. лица | Тип данных — Целое |
| Подномер счета | Число | Остальные 10 цифр, которые формируют номер счета Счетчик определит нам сквозную нумерацию, которая не зависит от группы и подгруппы счета. Это не совсем правильно. Мы должны нумеровать счета независимо. Но, поскольку пример учебный — мы сделали так для простоты. | Счетчик, Новые значения — Последовательные, Ключевое |
| Номер счета | В номере счета 14 цифр, поэтому, чтобы получить счет вида 2615… нам необходимо обеспечить сдвиг по регистрам на соответствующее число разрядов | Вычисляемое, Формула: [Группа счета]*1000000000000 + [Подгруппа счета]*10000000000 + [Подномер счета] | |
| Дата открытия | Дата | Счет должен обязательно иметь дату открытия | Дата/Время, Значение по умолчанию =Date(), Обязательное — Да |
| Дата закрытия | Дата | Дата/Время | |
| Договор | Ссылка на договор | Числовой, Длинное целое, Индексированное — Да, допускаются совпадения | |
| Сумма | Сумма, которая храниться на счете в данный момент | Денежный, Формат поля — Денежный |
Теперь заходим в схему данных и устанавливаем связи между:
«Юридические лица.Форма собственности» и «Формы собственности.ID» «Юридические лица.Директор» и «Физические лица.ИНН» «Юридические лица.Главный бухгалтер» и «Физические лица.ИНН» «Договоры.Договор с юр лицом» и «Юридические лица.Код ОКПО» «Договоры.Договор с физ лицом» и «Физические лица.ИНН»
Получаем примерно следующую схему базы данных депозитов:
0
Определяем набор данных для БД | Описание курса | Создание форм Access для редактирования данных
Источник: https://profmeter.com.ua/communication/learning/course/course19/lesson638/
Нормализация базы данных
Каждый программист обычно по-своему проектирует базу данных для программы, над которой работает. У одних это получается лучше, у других — хуже.
Качество спроектированной БД в немалой степени зависит от опыта и интуиции программиста, однако существуют некоторые правила, помогающие улучшить проектируемую БД.
Такие правила носят рекомендательный характер, и называются нормализацией базы данных.
- Процесс нормализации данных заключается в устранении избыточности данных в таблицах.
- Существует несколько нормальных форм, но для практических целей интерес представляют только первые три нормальные формы.
- Первая нормальная форма (1НФ) требует, чтобы каждое поле таблицы БД было неделимым (атомарным) и не содержало повторяющихся групп.
Неделимость означает, что в таблице не должно быть полей, которые можно разбить на более мелкие поля. Например, если в одном поле мы объединим фамилию студента и группу, в которой он учится, требование неделимости соблюдаться не будет. Первая нормальная форма требует, чтобы мы разбили эти данные по двум полям.
Под понятием повторяющиеся группы подразумевают поля, содержащие одинаковые по смыслу значения. Взгляните на рисунок:
| Студент 1 | Студент 2 | Студент 3 |
| Иванов И.И. | Петров П.П. | Сидоров С.С. |
Рис. 1.6. Повторяющиеся группы
Верно, такую таблицу можно сделать, однако она нарушает правило первой нормальной формы. Поля «Студент 1», «Студент 2» и «Студент 3» содержат одинаковые по смыслу объекты, их требуется поместить в одно поле «Студент», как в рисунке 1.4.
Ведь в группе не бывает по три студента, правда? Представляете, как будет выглядеть таблица, содержащая данные на тридцать студентов? Это тридцать одинаковых полей! В приведенном выше рисунке поля описывают студентов в формате «Фамилия И.О.». Однако если оператор будет вводить эти описания в формате «Фамилия Имя Отчество», то нарушается также правило неделимости.
В этом случае каждое такое поле следует разбить на три отдельных поля, так как поиск может вестись не только по фамилии, но и по имени или по отчеству.
Вторая нормальная форма (2НФ) требует, чтобы таблица удовлетворяла всем требованиям первой нормальной формы, и чтобы любое не ключевое поле однозначно идентифицировалось полным набором ключевых полей. Рассмотрим пример: некоторые студенты посещают спортивные платные секции, и ВУЗ взял на себя оплату этих секций. Взгляните на рисунок:
| № студента | Секция | Плата |
| Плавание | ||
| Скейтборд | ||
| Теннис | ||
| Плавание | ||
| Теннис |
Рис. 1.7. Нарушение второй нормальной формы
В чем здесь нарушение? Ключом этой таблицы служат поля «№ студента» — «Секция». Однако данная таблица также содержит отношение «Секция» — «Плата».
Если мы удалим запись студента № 110, то потеряем данные о стоимости секции по скейтборду. А после этого мы не сможем ввести информацию об этой секции, пока в нее не запишется хотя бы один студент.
Говорят, что такое отношение подвержено как аномалии удаления, так и аномалии вставки.
В соответствие с требованиями второй нормальной формы, каждое не ключевое поле должно однозначно зависеть от ключа.
Поле «Плата» в приведенном примере содержит сведения от стоимости данной секции, и ни коим образом не зависит от ключа — номера студента.
Таким образом, чтобы удовлетворить требованию второй нормальной формы, данную таблицу следует разбить на две таблицы, каждая из которых зависит от своего ключа:
| Ла студента | Секция |
| Плавание | |
| Скейтборд | |
| Теннис | |
| Плавание | |
| Тенине |
| Секция | Плата |
| Плавание | |
| Скейтборд | |
| Теннис |
Ключ: Секции
Ключ: № студента Рис. 1.8. Правильная вторая нормальная форма
Мы получили две таблицы, в каждой из которых не ключевые данные однозначно зависят от своего ключа.
Третья нормальная форма (3НФ) требует, чтобы в таблице не имелось транзитивных зависимостей между не ключевыми полями, то есть, чтобы значение любого поля, не входящего в первичный ключ, не зависело от другого поля, также не входящего в первичный ключ. Допустим, в нашей студенческой базе данных есть таблица с расходами на спортивные секции:
| Секция | Плата | Кол-во | Общая |
| студентов | стоимость | ||
| Плавание | |||
| Скейтборд | |||
| Теннис |
Рис. 1.9. Нарушение третьей нормальной формы
Как нетрудно заметить, ключевым полем здесь является поле «Секция». Поля «Плата» и «Кол-во студентов» зависят от ключевого поля и не зависят друг от друга. Однако поле «Общая стоимость» зависит от полей «Плата» и «Кол-во студентов», которые не являются ключевыми, следовательно, нарушается правило третьей нормальной формы.
Поле «Общая стоимость» в данном примере можно спокойно убрать из таблицы, ведь если потребуется вывести такие данные, нетрудно будет перемножить значения полей «Плата» и «Кол-во студентов», и создать для вывода вычисляемое поле.
Таким образом, нормализация данных подразумевает, что вы вначале проектируете свою базу данных: планируете, какие таблицы у вас будут, какие в них будут поля, какого типа и размера.
Затем вы приводите каждую таблицу к первой нормальной форме.
После этого приводите полученные таблицы ко второй, затем к третьей нормальной форме, после чего можете утверждать, что ваша база данных нормализована.
Однако такой подход имеет и недостатки: если вам требуется разработать программный комплекс для крупного предприятия, база данных будет довольно большой. При нормализации данных, вы можете получить сотни взаимосвязанных между собой таблиц.
С увеличением числа нормализованных таблиц уменьшается восприятие программистом базы данных в целом, то есть вы можете потерять общее представление вашей базы данных, запутаетесь в связях. Кроме того, поиск в чересчур нормализованных данных может быть замедлен.
Отсюда вывод: при работе с данными большого объема ищите компромисс между требованиями нормализации и собственным общим восприятием базы данных.
Лекция 2. ADO. Связь с таблицей MS Access.
С самого появления технологии баз данных программисты испытывали потребность в механизмах доступа к этим самым данным. Различные компании по-своему пытались предоставить им такую возможность.
Например, для работы с таблицами типа dBase была создана Система Управления Базами Данных (СУБД) Clipper. Для времен операционной системы MS-DOS — превосходное решение. Однако Clipper не мог работать ни с какими другими типами таблиц.
И чем больше типов данных появлялось, тем острее вставала необходимость разработать универсальный инструмент доступа, который мог бы работать с любым типом данных.
Механизм доступа к данным — это программный инструмент, позволяющий получить доступ к базе данных и ее таблицам. Как правило, это драйвер в виде *.dll файлов, который устанавливается на ПК разработчика (и клиента), и который используется программой для связи с БД.
⇐Ссылочная целостность || Оглавление || Сравнение BDE и ADO⇒
Источник: http://www.delphiplus.org/programirovanie-baz-dannih-v-delphi/normalizaciya-bazi-dannih.html
Нормализация
Последнее обновление: 02.07.2017
Нормализация представляет процесс разделения данных по отдельным связанным таблицам. Нормализация устраняет избыточность данных (data redundancy) и тем самым избежать нарушения целостности данных при их изменении, то есть избежать аномалий изменения (update anomaly).
Как правило, нормализация преимущественно применяется при восходящем подходе проектировании базы данных, то есть когда мы все атрибуты, которые надо сохранить в бд, группируем по сущностям, для которых затем создаются таблицы. Однако при нисходящем подходе, когда вначале выявляются сущности, а затем их атрибуты и связи между ними, нормализация также может применяться, например, для проверки корректности спроектированных таблиц.
В ненормализованной форме таблица может хранить информацию о двух и более сущностях. Также она может содержать повторяющиеся столбцы. Также столбцы могут хранить повторяющиеся значения. В нормализованной же форме каждая таблица хранит информацию только об одной сущности.
Нормализация предполагает применение нормальных форм к структуре данных. Существуют 7 нормальных форм.
Каждая нормальная форма (за исключением первой) подразумевает, что к данным уже была применена предыдущая нормальная форма.
Например, прежде чем применить третью нормальную форму к данным должна быть применена вторая нормальная форма. И строго говоря, база данных считается нормализованной, если к ней применяется третья нормальная форма и выше.
- Первая нормальная форма (1NF) предполагает, что сохраняемые данные на пересечении строк и столбцов должны представлять скалярное значение, а таблицы не должны содержать повторяющихся строк.
- Вторая нормальная форма (2NF) предполагает, что каждый столбец, не являющийся ключом, должен зависеть от первичного ключа.
- Третья нормальная форма (3NF) предполагает, что каждый столбец, не являющийся ключом, должен зависеть только от первичного ключа.
- Нормальная форма Бойса-Кодда (BCNF) является немного более строгой версией третьей нормальной формы.
Четвертая нормальная форма (4NF) применяется для устранения многозначных зависимостей (multivalued dependencies) — таких зависимостей, где столбец с первичным ключом имеет связь один-ко-многим со столбцом, который не является ключом. Эта нормальная форма устраняет некорректные отношения многие-ко-многим.
Пятая нормальная форма (5NF) разделяет таблицы на более малые таблицы для устранения избыточности данных. Разбиение идет до тех пор, пока нельзя будет воссоздать оригинальную таблицу путем объединения малых таблиц.
Шестая нормальная форма (domain key normal form / 6NF). Каждое ограничение в связях между таблицами должно зависеть только от ограничений ключа и ограничений домена, где домен представляет набор допустимых значений для столбца.
Эта форма предотвращает добавление недопустимых данных путем установки ограничения на уровне отношений между таблицами, но не на уровне таблиц или столбцов.
Данная форма, как правило, не применима на уровне СУБД, в том числе и в SQL Server.
Функциональная зависимость
Ключевым понятием нормализации является функциональная зависимость. Функциональная зависимость описывает связь между атрибутами отношения. Например, если атрибут В функционально зависит от атрибута А (А → В), то каждое значение атрибута А связано только с одним значением атрибута В.
Причем атрибуты А и В могут состоять из одного или нескольких атрибутов. То есть, если две строки имеют одно и то же значение атрибута А, то они обязательно имеют одно и то же значение атрибута В. При этом для одного значения атрибута В могут существовать несколько различных значений атрибута А.
Атрибут А в этой зависимости еще называется детерминантом.
Например, возьмем следующую таблицу, которая представляет университетские курсы:
| Course | Teacher | Position |
| Математика | Смит | Профессор |
| Алгориты | Адамс | Ассистент |
| JavaScript | Адамс | Ассистент |
Здесь атрибут Teacher функционально зависит от атрибута Course (Course → Teacher). То есть зная название курса, мы можем определить его преподавателя.
И в этом случае можно говорить, что между атрибутами Course и Teacher есть связь 1:1, а между Teacher и Course связь 1:N, так как есть несколько курсов, которые может вести один преподаватель.
При этом атрибут Course функционально не зависит от атрибута Teacher.
Кроме того, здесь можно проследить еще две функциональных зависимости. В частности, атрибут Position зависит от атрибута Teacher (Teacher → Position). Зная имя преподавателя, мы можем определить его должность.
И также атрибут Position функционально зависит от атрибута Course — зная название курса, мы можем сказать должность преподавателя.
В таблице в нормализованной базе данных единственным детерминантом должен быть атрибут, который является первичным ключом. А все остальные атрибуты должны функционально зависеть от первичного ключа.
Например, в данном случае мы можем взять в качестве первичного ключа название курса с учетом, что курсы могут иметь только уникальные названия.
Однако должность преподавателя в данном случае будет зависеть сразу от двух атрибутов — от Course и Teacher.
И подобные зависимости могут свидетельствовать о том, что база данных и конкретно таблица курсов имеет недостатки в проектировании и может быть источником аномалий обновления.
Источник: https://metanit.com/sql/tutorial/2.1.php
Загрузка...
