Проектирование базы данных (бд) коммерческого предприятия [курсовая №87140]

Система хранения информации в базах данных

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

база данных;
таблица;
запись.

База данных

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

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

Система хранения информации в базах данных

Таблица

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

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

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

Она может быть представлен в виде обычного Exсel-файла, или простого набора строк и столбцов.

ТОП-30 IT-профессий 2023 года с доходом от 200 000 ₽

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

Подборка содержит только самые востребованные и высокооплачиваемые специальности и направления в
IT-сфере. 86% наших учеников с помощью данных материалов определились с карьерной целью на ближайшее
будущее!

Скачивайте и используйте уже сегодня:

Александр Сагун
Исполнительный директор Geekbrains

Топ-30 самых востребованных и высокооплачиваемых профессий 2023

Поможет разобраться в актуальной ситуации на рынке труда

Подборка 50+ ресурсов об IT-сфере

Только лучшие телеграм-каналы, каналы Youtube, подкасты, форумы и многое другое для того, чтобы узнавать новое про IT

ТОП 50+ сервисов и приложений от Geekbrains

Безопасные и надежные программы для работы в наши дни

Получить подборку бесплатно

pdf 3,7mb
doc 1,7mb

Уже скачали 19648

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

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

Запись

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

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

Создадим для сайта новую базу данных и дадим ей название «private diary».
Создадим в БД новую таблицу с именем «diary log» и определим там следующие столбцы:
День недели (тип: текст);
День (тип: дата);
Номер записи (тип: число);
Настроение (тип: число; от 0 (плохое) до 5 (отличное));
Комментарий (тип: текст).
При сохранении формы будем добавлять в таблицу diary_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

Описание нормализации

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

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

Что такое «несогласованные зависимости»? Пользователь, которому нужно узнать, например, адрес определенного клиента, вполне обоснованно будет искать его в таблице Customers (клиенты), но искать в ней сведения о зарплате сотрудника, который работает с этим клиентом, не имеет смысла. Зарплата сотрудника связана с сотрудником (зависит от него), поэтому эти сведения следует хранить в таблице Employees (сотрудники). Несогласованные зависимости могут затруднять доступ к данным, так как путь к данным при этом может отсутствовать или быть неправильным.

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

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

В описаниях ниже приведены соответствующие примеры.

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

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

Записи могут зависеть только от первичного ключа таблицы (составного ключа, если необходимо). Возьмем для примера адрес клиента в системе бухгалтерского учета. Этот адрес необходим не только таблице Customers, но и таблицам Orders, Shipping, Invoices, Accounts Receivable и Collections. Вместо того чтобы хранить адрес клиента как отдельный элемент в каждой из этих таблиц, храните его в одном месте: или в таблице Customers, или в отдельной таблице Addresses.

Кейс «Задание на разработку»

Рассмотрим ситуацию постановки задачи СВОЕМУ программисту. Т.е. пишем техническое задание не для клиента, а своему, такому же раздолбаю, который сидит в соседнем отделе и носит гордое имя «программист». Ах, у Вас он даже в офис не ходит? Дома работает? Что ж, скайп нам в руки. А у Вас? Вы вообще его лично никогда не видели? Значит ситуация сложнее.
И ведь он, поганец такой, требует, чтоб ему дали конкретную работу. И не грузили всякой ерундой и не лили воду на мельницу.
В идеале, было бы вообще замечательно, если бы можно было бы из технического задания, которое мы подготовили для клиента, нарезать небольшие задания и раздавать их разным исполнителям. А затем в проджекте галочки об исполнении ставить.

Но ведь нет, на практике же приходится давать устные пояснения по каждому пункту. Объяснять, что имелось в виду вот в этом предложении ТЗ в тот момент, когда его формулировал для клиента.

Вот и предлагаю способ сохранить нервы себе и уверенность в Вас со стороны программиста.

1 стартмани

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

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

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

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

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

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

Чтобы привести базу к третьей нормальной форме, надо:

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

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

3. Создайте или выделите первичные ключи. Каждая таблица должна иметь первичный ключ. Для примера с клиентами это будут city ID и state ID.

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

Подсказки:

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

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

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

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

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

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

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

Нормальные формы.

Правила нормализации, применяемые к таблице, уменьшают проблемные области, «поднимая» таблицы на более высокий уровень согласованности данных, особенно в процессе добавления, обновления и удаления записей. Первая нормальная форма (1NF) — является первым правилом, вторая — вторым и тд. Давайте рассмотрим эти правила подробнее.

Первая нормальная форма (1NF)

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

Вместо этого, мы должны разместить данные в таблице следующим образом:

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

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

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

В таблице выше, существуют следующие зависимости:

{SSN} → {EMPLOYEE_NAME}{SSN} → {PROJ_HOURS}

Также,

{PROJECT_NO} → {PROJECT_NAME}{PROJECT_NO} → {PROJECT_HOURS}

Это грубое нарушение 2NF, потому что значение полей PROJECT_HOURS и PROJECT_NAME в каждой записи функционально зависимы от PROJECT_NO. Кроме того, EMPLOYEE_NAME и PROJ_HOURS однозначно определяются значением поля SSN. Чтобы привести данные к 2NF в данном случае мы можем «разложить» таблицу EMPLOYEE_PROJECT на несколько таблиц:

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

Чтобы привести таблицу в третью нормальную форму (3NF), она должна находится во второй нормальной форме (2NF) и, самое главное, не должна содержать данные с транзитивными зависимостями. Транзитивная зависимость — это случай, когда X→Y, Y→Z, X→Z. Это значит, что любое не ключевое поле не должно быть зависимо от поля, которое не является первичным ключом таблицы. Например:

Здесь, существуют зависимости:

{SSN} → {EMPLOYEE_NAME}
{SSN} → {BIRTH_DATE}
{SSN} → {DEPT_NAME}
{SSN} → {DEPT_ADDRESS}

Однако, аномальной является следующая зависимость:

{DEPT_NAME} → {DEPT_ADDRESS}

потому что DEPT_NAME не является ключом. Мы можем устранить эту проблему, разделив таблицу на 2 таблицы.

Нормальная форма Бойса-Кодда (BCNF)

В большинстве случаев, BCNF — это эквивалент 3NF. Правда эта форма строже, чем третья нормальная форма. Любая таблица, находящаяся в BCNF, находится в 3NF, но не наоборот.

BCNF — это нетривиальная функциональная зависимость X→Y в которой X, находящийся в ее левой части, является первичным ключом.

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

{SSN} → {EMPLOYEE_NAME}
{SSN} → {BIRTH_DATE}

В таблице EMPLOYEE первичным ключом является поле SSN. Это нетривиальная функциональная зависимость, таблицы EMPLOYEE, в левой части которой находится атрибут SSN. Так как SSN является первичным ключом, функциональная зависимость не нарушает условий BCNF.

{PROJECT_NO} → {PROJECT_NAME}
{PROJECT_NO} → {PROJECT_DURATION}

Таблица PROJECT также находится в BCNF.

{DEPT_NO, SSN} → {PROJECT_NO, DURATION}
{PROJECT_NO} → {DURATION, DEPT_NO}

Однако, PROJECT_INFO не находится в BCNF, потому что PROJECT_NO не является первичным ключом. Не может быть пары строк, представляющих 2 разных SSN, работающих в том же PROJECT_NO и DEPT_NO. Например:

Функциональная зависимость PROJECT_NO → DURATION нетривиальна. Таким образом, таблица не удовлетворяет определению BCNF. Мы можем устранить эту проблему, если перепроектируем эту таблицу таким образом, чтобы все полученные в результате таблицы приняли BCNF. Например:

Этапы проектирования базы данных

Этап начальной разработки

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

Концептуальное проектирование базы данных

анализ требований к базе данных, выявление представлений конечных пользователей и требований к обработке транзакций;
определение сущностей, атрибутов и связей;
разработка ER-диаграмм (от ER — Entity-Relationship — Сущность-Связь);
нормализация;
проверка модели данных, выявление основных процессов (правила ввода, обновления и удаления данных);
проверка отчётов, запросов, представлений, целостности, совместного использования и безопасности.

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

Согласно сведениям из информационно-аналитической системы «Результаты научной деятельности» (http://science.asu.edu.ru) на базы данных приходится четверть всех свидетельств о госрегистрации в университете (Рис. 1):

Рис. 1. Диаграмма распределения числа зарегистрированных РИД по видам

Популярность этого вида РИД легко объяснить: регистрировать в качестве базы данных можно практически всё. Это могут быть результаты расчётов, экспериментов, наблюдений; словари; статьи на сайте и т.п. То есть любой структурированный набор текстовых или числовых данных, объединённых общей идеей или тематикой.

По результатам исследования открытого реестра баз данных (https://rospatent.gov.ru/opendata/7730176088-bd), авторы регистрируют лекции, задания, глоссарии терминов, рабочие программы и учебно-методические комплексы.

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

Правовая охрана и возможность предоставления лицензии третьим лицам. Авторы хотят защитить права на собственные разработки и материалы.
Это сравнительно простой способ получить в свой послужной список ещё один РИД. Здесь не надо общаться с издательством, неоднократно дорабатывать рукопись, ждать выхода издания в свет.

Как выбрать систему управления базами данных?

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

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

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

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

Как и во многих других системах, СУБД потребуется дополнительная память и ЦП, поэтому организациям крайне важно подумать, смогут ли они удовлетворить эту потребность. Однако у СУБД есть явные преимущества, особенно при работе с большими объемами потенциально конфиденциальных данных, как в случае с учреждениями здравоохранения

Нарушения правил нормализации

Убедившись, что база данных в 3НФ поможет гарантировать надёжность и жизнеспособность, не нужно полностью нормализовывать все базу, с которыми вы работаете. Перед тем, как использовать эти методы, имейте ввиду, что это может иметь долгосрочные разрушающие последствия.

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

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

Ссылки:

Введение
Первая нормальная форма
Вторая нормальная форма
Вики о нормализации
Mysql Workbench — программа для проектирования баз данных

Пятая нормальная форма

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

Такая вот теория… Разработаны специальные формальные математические методы нормализации таблиц реляционных баз данных. На практике же толковый проектировщик баз данных, детально познакомившись с предметной областью, как правило, достаточно быстро набросает структуру, в которой большинство таблиц находятся в четвертой нормальной форме:).

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

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

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

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

Предположим, мы нарушили 1НФ и стали хранить фамилии, имена и отчества клиентов в одной колонке. Пока операторы вносили информацию, эта ошибка проектирования особенно не мешала, Однако, на следующем этапе понадобилась отчётность, в которой ФИО клиентов выводились бы в виде фамилии и инициалов. Оказалось, что некоторые записи вместо «Сидоров Петр Иванович» содержат «Петр Иванович Сидоров», в других отчества нет вовсе, в третьих фамилия двойная и не всегда записана через тире, в четвёртых после фамилий расставлены запятые. Эту проблему пришлось решать программированием совсем нетривиальной логики с элементами распознавания по словарю. Было потрачено много времени и средств, но в отчётности нет-нет да и проскакивали непонятные значения типа «Оглы П.Б.Б.».

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

Признаки БД, чем отличаются от электронных таблиц

Любая база данных обладает набором стандартных признаков. Основными из них являются:

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

Примечание

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

Рассмотреть базу данных целесообразно на примере Access. Это специальное приложение, в котором хранятся упорядоченные данные, что допускает применение и других приложений (к примеру, Excel). В обоих случаях информация представлена в табличном виде.

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

Excel не предусматривает установку реляционных связей между таблицами. Благодаря связям в Access, исключается ненужное дублирование информации и ошибки при обработке данных. Также допускается совместное использование данных из разных таблиц.
Access обеспечивает хранение в таблицах нескольких миллионов записей. При этом скорость их обработки сохраняется на высоком уровне.
Access включает возможность организации одновременной работы с базой данных нескольких десятков пользователей, которые в реальном времени могут видеть изменения, выполненные другими пользователями.
Данные в Access сохраняются автоматически после завершения редактирования текущей записи. В случае Excel для этого нужно запустить команду «Сохранить».
Таблицы в Access характеризуются заранее предопределенной жесткой структурой. Невозможно в один столбец записать разные типы данных или форматировать отдельные ячейки.
Прямо в таблице базы данных Access нельзя выполнять вычисления, подобные действия реализуются с применением запросов.

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

Чтобы привести базу к третьей нормальной форме, надо:

Рассмотренная в качестве примера база данных с записями о клиентах, созданы две новых таблицы для хранения информации о городах и штатах.

Подсказки:

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

Немного терминологии

Базой данных является «представленная в объективной форме совокупность самостоятельных материалов (статей, расчетов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ)» (https://rospatent.gov.ru/ru/stateservices/gosudarstvennaya-registraciya-programmy-dlya-elektronnyh-vychislitelnyh-mashin-ili-bazy-dannyh-i-vydacha-svidetelstv-o-gosudarstvennoy-registracii-programmy-dlya-elektronnyh-vychislitelnyh-mashin-ili-bazy-dannyh-ih-dublikatov).

Определение по ГОСТ 20886 (http://docs.cntd.ru/document/gost-20886-85):

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

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

В заявлении на государственную регистрацию базы данных указываются вид и версия системы управления базой данных (СУБД):

Система управления базами данных — совокупность программ и языковых средств, предназначенных для управления данными в базе данных, ведения базы данных и обеспечения взаимодействия её с прикладными программами (ГОСТ 20886, http://docs.cntd.ru/document/gost-20886-85).

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

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

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

Чтобы привести таблицу к 1НФ, нужно соблюсти два правила:

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

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

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

Чтобы привести таблицу к первой нормальной форме, следует:

Найти все поля, которые содержат многосоставные части информации. На рисунке выше, поле message date содержит день, месяц, год и время, которое можно разбить на составные части, но в данном примере такая детализация даты не нужна. Mysql может работать и с таким форматом — благодаря типу DATETIME. В этом примере разбито имя пользователя на имя и фамилию. Еще примерами неудачных решений могут быть поля, в которых хранятся сразу все телефоны человека (мобильный, рабочий) или его интересы (готовка, танцы).
Те данные, которые можно разбить на составные части, нужно выносить в отдельные поля. На рисунке выше так разнесено полное имя на имя и фамилию.
Выносите повторяющиеся данные в отдельную таблицу. В примере с форумом такой проблемы нет, поэтому возьмем в качестве примера таблицу, содержащую информацию о фильмах. Там есть несколько полей actor, которые являются повторяемыми. Повторяемые поля тут несут две проблемы. Если хранить информацию об актерах таким образом, то их число будет лимитировано числом таблиц. Даже если их будет 100, то все равно это будет пределом для некоторых фильмов. И вторая проблема — будет большое количество пустых(NULL) ячеек для большинства остальных записей, чего также следует избегать. Решением этой проблемы станет создание отдельной таблицы для актеров, куда будет заносится информация обо всех необходимых фильмах. Имена актеров также разбиты, чтобы соблюсти атомарность. Также в этой таблице присутствует свой первичный ключ, что является необходимым условием для нормализации.
Дважды проверьте, все ли таблицы подходят под условия первой нормальной формы.

Подсказки

Простейший путь приведения к 1НФ — это пройтись глазами по всем столбцам. Проверьте каждый ряд на отсутствие повторения схожих данных и делимости.
Разные источники трактуют процесс нормализации по своему, в основном более сухим, техническим языком. Более важен результат нормализации, а не повторение правил и умных слов.

Ключи

Ключом (key) называется набор атрибутов, однозначно определяющий запись. Ключи делятся на два класса: простые и составные.
Простой ключ состоит только из одного атрибута. Например, в базе «Паспорта граждан страны» номер паспорта будет простым ключом: ведь не бывает двух паспортов с одинаковым номером.
Составной ключ состоит из нескольких атрибутов. В той же базе «Паспорта граждан страны» может быть составной ключ со следующими атрибутами:
фамилия, имя, отчество, дата рождения. Это — как пример, т. к. этот составной ключ, теоретически, не обеспечивает гарантированной уникальности записи.
Также существует несколько типов ключей, о которых рассказано далее.

Возможный ключ

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

Первичные ключи

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

Альтернативные ключи

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

Внешние ключи

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

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