Как называется строчка в таблице бд

Устройство реляционной базы данных

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

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

Устройство реляционной базы данных – таблицы, строки, столбцы

Таблицы, строки, столбцы это всем знакомые, элементы базы данных. В математике эти элементы называют: отношения, кортежи, атрибуты в множествах.

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

Атрибут множества, это название столбца в таблице БД. Математически, атрибут это множество, названий столбцов. Каждое название столбца уникально и неупорядочено. То есть, мы можем «добраться» до уникального названия столбца не затрагивая другие столбцы.

Очень важна уникальность атрибутов (названий столбцов) в рамках базы данных. Достигается уникальность столбцов, добавлением в его названия имя таблицы данных.

О неупорядоченности атрибутов

Математически, множество атрибутов: B.4, B.89, B.55, B.3, B.99, точно такое же, как множество: B.89, B.55, B.4, B.99, B.3. Но на практике, мы не можем вызывать столбцы по названию в произвольном порядке. Для упорядочивания вызова и нужен структурный язык. Для реляционных баз данных структурный язык это язык: SQL. В нем упорядоченный вызов столбцов поатрибутам выглядит так:

• SELECT B.4, B.89, B.55, B.3, B.99 FROM B

• SELECT B.89, B.55, B.4, B.99, B.3 FROM B

Столбцы реляционной базы данных

Столбцы данных математически называют кортежи. Каждый кортеж имеет столько атрибутов, сколько строк в таблице. При этом:

• Содержание столбцов должно быть уникально;
• Математически кортежи (столбцы) неупорядочены, как и строки (атрибуты). То есть, каждый столбец можно вызвать, не затрагивая остальные.

Выводы

В пользовательском «общении» с базами данных мы имеем дело, с столбцами, строками, таблицами. Математически в реляционной (табличной) теории их называют: атрибуты, кортежи и отношения. Столбцы могут именоваться колонками (colums), строки могут именоваться записями (records).

Отмечу, чаще приходится иметь дело с такими названиями:

• База данных это таблица (одна или несколько);
• Строки в таблицы, называют запись. Это основная логическая единица БД;
• Столбцы в таблице называют поле. Каждое поле имеет свой тип.

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

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

Пример базы данных MySQL

Возьмем базу данных (таблицы) магазина, вернее одну таблицу базы данных всеx товаров магазина. Для справки это магазин на платформе Moguta, таблица: mg_product.

Это сама база данных состоящая из таблиц. Устройство реляционной базы данных. Это таблица базы данных товаров на сайте.

Основы SQL: работа с таблицами и их соединением

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

В основном БД представлены таблицами. С ними совершают разнообразные действия:

• объединяют тем или иным способом;
• удаляют;
• корректируют;
• сохраняют;
• выводят на экран.

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

Определение SQL

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

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

Особенности – что умеет язык

При помощи SQL пользователь/разработчик сможет:

• заполучать доступ к информации в системах управления БД;
• производить описание данных, их структур;
• определять электронные материалы в «табличном хранилище», управляя оными;
• проводить взаимодействие с иными языками при помощи модулей, библиотек и компиляторов SQL;
• создавать новые таблички, удалять старые;
• заниматься созданием представлений, хранимых процедур и функций.

Также при работе с таблицами БД за счет SQL можно настраивать доступ к представлениям, таблицам и процедурам. Главное знать, каким именно образом действовать.

В SQL существуют всевозможные команды, использованием которых удается производить те или иные манипуляции. Далее будет рассказано всего об одном достаточно важном моменте. А именно – как использовать оператор Join. Он пригодится и новичкам, и тем, кто долгое время работает с таблицами и БД.

Что представляет собой JOIN

JOIN – команда/оператор, который используется, когда нужно произвести объединение нескольких таблиц в базах данных. Вследствие нее происходит преобразование двух строк в одну. И не обязательно оные окажутся в разных табличках. JOIN может работать в пределах одного «хранилища» информации.

Команда выполняется при перечислении двух и более таблиц в операторе SQL. Определение JOIN – соединение. Синтаксис здесь довольно простой. Но стоит обратить внимание на то, что вариантов объединения несколько. У каждого – своя запись.

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

• простое;
• left outer join;
• right outer join;
• full outer join.

Каждый join запрос в SQL имеет собственные нюансы. О них будет рассказано далее. Разобраться, какой вариант подойдет в том или ином случае поможет простая математика. Там тоже есть объединение. Если разобрать соответствующий вопрос там, в программировании добиться успеха удастся в считанные минуты.

Важно: есть еще один вариант – cross join. Встречается на практике не слишком часто, но помнить о подобном раскладе тоже нужно.

Проще простого – Inner

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

Для реализации поставленной задачи применяется INNER JOIN. Чтобы лучше понимать данный процесс, стоит составить диаграмму Венна:

• нарисовать круг – пусть это будет «таблица 1»;
• рядом, задевая область первой фигуры, изобразить второй круг – это «таблица 2»;
• закрасить область пересечения – это и есть результат операции inner join.

Рисунок выше – наглядный пример диаграммы Венна. С его помощью удастся разобраться в принципах «простого» объединения нескольких табличек.

Запись

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

Здесь никаких проблем возникнуть не должно. Код легко читается:

• выбрать колонки;
• from table1 – из первой таблицы;
• объединить с таблицей 2.

Для наглядного примера стоит рассмотреть несколько таблиц с информацией, а также принцип joins типа inner.

Наглядный пример

Пусть будет дана таблица под названием customer. В ней такая информация:

Далее – создается таблица orders:

Теперь нужно joining поля в этих хранилищах информации простым объединением. Для реализации поставленной задачи составляется команда типа:

SELECT customers.customer_id, orders.order_id, orders.order_date FROM customers INNER JOIN orders ON customers.customer_id = orders.customer_id ORDER BY customers.customer_id;

В конечном итоге при обработке запроса на экран будет выведен следующий результат:

Здесь выбираются поля в таблице, которые имеют одинаковые значения customer_id в обоих хранилищах. Поэтому другие поля будут пропущены. А строчка, где order_id = 5 в orders опускается, так как customer_id идут со значениями null. То есть, их нет в customers.

Left Join

В отличие от предыдущего объединения, left join – это возврат всех строк из левой таблицы по установленным принципам. Это – левостороннее соединение, осуществляемое через условие ON. Вследствие обработки операции:

• проводится проверка на соответствие условия соединения;
• если оно выполняется – строчка из второй прибавляется к первой таблице.

Именно такое описание можно дать команде left join. Представив его в виде диаграмм, необходимо запомнить следующее представление:

Вся закрашенная область – это результат обработки команды left join в языке SQL.

Запись и пример

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

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

Для примера необходимо взять таблицу с информацией:

Вторая база данных:

Названия тут будут такими же, как и в прошлом случае. Теперь составляется запрос выполнения левостороннего слияния:

После обработки оного на экране появятся всего 6 записей:

Так произошло, потому что left join произвел внутреннее объединение только строки customers и те строчки из orders, где объединенные поля обладают равными значениями. Также стоит запомнить следующие важные сведения:

• когда значение в customer_id из customers отсутствует в orders, поля «ордерс» отображаются в виде null;
• если выставленный параметр слияния не выполняется, поля/строчки «отбрасываются».

Ничего трудного. Такой тип объединения табличек в программировании и базах данных тоже встречается не слишком редко.

Right Join

Описание right join предельно простое – правостороннее соединение. Результатом будут служить строчки из второй таблицы, соответствующие выставленному условию слияния. Наглядно это выглядит так:

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

О синтаксической записи и примерах

Синтаксис в команды будет иметь вид:

Чтобы понять, как работает right join в языке SQL, рекомендуется обратить внимание на наглядный пример. Он опять осуществляется с табличками customer и orders. Пример будет прописан в операторе SELECT.

Даны две таблицы с информацией:

Далее, чтобы joined две таблички по правостороннему принципу, требуется отправить соответствующий запрос. Он обладает такой формой записи:

Как только операция пройдет обработку, на экране устройства появится результат. Он будет состоять из пяти элементов:

• возвращаются строки из orders – все;
• на экран дополнительно выводятся строчки из customers, которые имеют с «ордерс» одинаковые значения;
• если customers_id в orders отсутствует в «кастомерс», соответствующие поля имеют значение null.

Но и это еще не все. Для полного осознания запросов слияния электронных материалов, требуется в первую очередь изучить все доступные расклады. Их осталось еще 2. Встречаются на практике не слишком часто, из-за чего доставляют немалые хлопоты. Особенно тем, кто занимается запросовым языком относительно недавно.

По полной программе

Предпоследний вариант, который предусматривает join в языке SQL – это full. Можно назвать данный процесс созданием единой таблицы. Информациях из обеих БД будет выведена на экран. Здесь не важно, где именно осуществляется непосредственное пересечение полей.

При full join происходит:

• проверка на невыполнение условия;
• вывод на экран всех строчек из левой и правой таблиц со значениями null, когда условие не выполнено.

Выглядит это так:

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

Как записывать и применять

Форма записи окажется такого типа:

Full – это внутреннее соединение всех полей в табличках предоставленных баз данных. Для того, чтобы намного лучше разобраться в этом вопросе, составляются таблички:

Они называются так же, как и предлагал последний наглядный пример. Запрос обладает следующим видом:

Перекрестным типом

Еще один довольно интересный подход, который относится к основным – это cross. Называется перекрестным. Ин6огда – декартово. При его использовании происходит генерация того же результата, что и при вызове двух таблиц без рассматриваемой команды. Это значит, что:

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

Так, если в таблице1 a записей, а в таблице2 b, результирующей окажется таблица a x b полей. В виде диаграммы представить подобный процесс проблематично. Она только запутает разработчиков.

Обладает запрос следующим синтаксисом:

Внимание: cross join – это декартово произведение. Так будет проще понять, о чем идет речь.

Комбинации

Для того, чтобы объединять пары табличек, можно воспользоваться self join. Чтобы разобраться в принципах работы запроса, необходимо рассмотреть пример. Сам запрос выглядит так:

Представить такое произведение множеств наглядно тоже проблематично. Зато на примере – нет. Тут показано, что у Гарри нет начальника.

Исключение

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

Чтобы воспользоваться подобным приемом, не нужно знать ни декартово произведение, ни какие-то другие сложные понятия. В запрос добавляется оператор Where.

А вот пример записи команды:

Планы исполнения

Для того, чтобы грамотно использовать join в SQL, нужно учитывать планы исполнения запросов. То, как именно (в какой последовательности) будет происходить обработка операторов и необходимые вычисления.

• from;
• join;
• where.

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

Важно: для того, чтобы ускорить обработку команд, важно использовать кластерные индексы. Они применяются Server Query Optimizer для обеих таблиц. Автоматическое создание кластерных индексов производится для первичных ключей. С остальными придется производить соответствующую настройку.

Описание join в языке SQL не должно вызывать вопросов. А если хочется лучше понять, что это такое, а также разобраться в принципах работы queries, стоит посетить дистанционные специализированные курсы. По окончанию обучения выдается сертификат, подтверждающий знания и навыки в выбранном направлении.

База данных — определение

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

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

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

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

В настоящее время наиболее известными СУБД являются: Oracle Database, MS SQL Server, MySQL (MariaDB) и ACCESS. Последняя входит в состав профессионального офисного пакета Microsoft Office.

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

Понятие базы данных

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

База данных (БД) – совокупность организованной информации, относящейся к определённой предметной области, предназначенная для длительного хранения во внешней памяти компьютера и постоянного применения.

Виды баз данных

1. Фактографическая – содержит краткую информацию об объектах некоторой системы в строго фиксированном формате;
2. Документальная – содержит документы самого разного типа: текстовые, графические, звуковые, мультимедийные;
3. Распределённая – база данных, разные части которой хранятся на различных компьютерах, объединённых в сеть;
4. Централизованная – база данных, хранящихся на одном компьютере;
5. Реляционная – база данных с табличной организацией данных;
6. Неструктурированная (NoSQL) — база данных, в которой делается попытка решить проблемы масштабируемости и доступности за счёт атомарности (англ. atomicity) и согласованности данных, но не имеющих четкой (реляционной) структуры.

Одно из основных свойств БД – независимость данных от программы, использующих эти данные. Работа с базой данных требует решения различных задач, основные из них следующие:

• создание базы;
• запись данных в базу;
• корректировка данных;
• выборка данных из базы по запросам пользователя.

Задачи этого списка называются стандартными .

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

База данных в разных системах имеет различную структуру.

В ПВЭМ обычно используются реляционные БД – в таких базах файл является по структуре таблицей. В ней столбцы называются полями, строки – записями.

В БД содержатся банные некоторого множества объктов. Каждая запись содержит данные одного объекта. Каждая такая БД определяется именем файла, списком полей, шириной полей. Например, БД Школа (Ученик, Класс, Адрес).

Примером БД может служить расписание движения поездов или автобусов. Здесь каждая строчка – запись отражает данные строго одного объекта. База включает поля: номер рейса, маршрута следования, время отправления и т.д.

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

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

Объекты для работы с базами данных

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

• набор данных
• источник данных
• визуальные элементы управления

В нашем случае эта триада реализуется в виде:

• Table
• DataSource
• DBGrid

Table подключается непосредственно к таблице в базе данных. Для этого нужно установить псевдоним базы в свойстве DataBaseName и имя таблицы в свойстве TableName, а затем активизировать связь: свойство Active = true .

Однако, поскольку Table является невизуальным компонентом, хотя связь с базой и установлена, пользователь не в состоянии увидеть какие – либо данные. Поэтому необходимо добавить визуальные компоненты, отображающие эти данные. В нашем случае это сетка DBGrid. Сетка сама по себе «не знает», какие данные ей нужно отображать, её нужно подключить к Table, что и делается через компонент – посредник DataSource .

А зачем нужен компонент – посредник? Почему бы сразу не подключаться к Table?

Допустим, несколько визуальных компонентов – таблица, поля ввода и т.п. подключены к таблице. А нам нужно быстро переключить их все на другую подобную таблицу. С DataSource это сделать несложно — достаточно просто поменять свойство DataSe t, а вот без DataSource пришлось бы менять указатели у каждого компонента.

Приложения баз данных – нить, связывающая БД и пользователя:

БД => набор данных –=> источник данных => визуальные компоненты => пользователь

• Table(таблица, навигационный доступ)
• Query(запрос, реляционный доступ)

• Сетки DBGrid, DBCtrlGrid
• Навигатор DBNavigator
• Всяческие аналоги Lable, Editи т.д.
• Компоненты подстановки

Типы данных в базах

В Access можно определить следующие типы полей:

• Текстовый – текстовая строка; максимальная длина задаётся параметром «размер», но не может быть больше 255
• Поле МЕМО – текст длиной до 65535 символов
• Числовой – в параметре «Размер поля» можно задать поле: байт, целое, дейсвительное и т.п.
• Дата/время – поле, хранящее данные о времени.
• Денежный – специальный формат для финансовых нужд, по сути являющийся числовым
• Счётчик – автоинкрементное поле. При добавлении новой записи внутренний счётчик таблицы увеличивается на единицу и записывается в данное поле новой записи. Таким образом, значения этого поля гарантированно различны для разных записей. Тип предназначен для ключевого поля
• Логический – да или нет, правда или ложь, включен или выключен
• Объект OLE– в этом поле могут храниться документы, картинки, звуки и т.п. Поле является частным случаем BLOB– полей (BinaryLargeObject), встречающихся в различных базах данных
• Гиперссылка – используется для хранения ссылок на ресурсы Интернета. Встречается не во всех форматах баз данных. К примеру, такого типа нет в dBaseи Paradox
• Подстановка

Типы данных в таблицах Access

• Текстовый
• Поле МЕМО
• Числовой
• Дата\время
• Денежный
• Счётчик
• Логический
• Объект OLE
• Гиперссылка

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

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

Основные понятия и элементы баз данных

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

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

Лишь только появились и распространились компьютеры, почти сразу на них возложили тяжёлый и кропотливый труд по обработке и структурированию данных, появились базы данных (БД) в их нынешнем понимании.

Согласно современным требованиям к базам данных, информация, содержащаяся в них, должна быть:

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

Реляционная модель баз данных была предложена Эдгаром Коддом в конце 70-х годов. В рамках этой модели база данных представляет собой набор таблиц, связанных друг с другом отношениями. При достаточной простоте (а значит, и удобстве реализации на компьютере) данная модель обладает гибкостью, позволяющей описывать сложно структурированные данные. Кроме того, для этой модели достаточно глубоко проработано теоретическое обоснование, что также даёт возможность эффективнее использовать компьютер при создании базы данных и работе с ней. В плане правил связи в реляционной модели реализуется отношение «один–ко–многим» связи между таблицами. Это значит, что одной записи в главной таблице соответствует несколько записей в подчинённой таблице (в том числе может не соответствовать ни одной записи). Другие типы связей: «один-к-одному», «много-к-одному» и «много-ко-многим» — можно свести к данному типу «один-ко-многим». Реляционные базы данных состоят из связанных таблиц.

Таблица представляет собой двумерный массив, в котором хранятся данные. Столбцы таблицы (в рамках принятых обозначений БД) называются полями, строки – записями. Количество полей таблицы фиксировано, количество записей – нет. Фактически таблица – нефиксированный массив записей с одинаковой структурой полей в каждой записи. Добавить в таблицу новую запись не составляет труда, а то время как добавление нового поля влечёт за собой рестрктуризацию всей таблицы и может вызвать определённые трудности. В качестве значений полей в записях могут храниться числа, строки, картинки и т.д. Таблицы баз данных хранятся на жёстком диске (на локальном компьютере или на сервере баз данных – в зависимости от типа БД). Одной таблице соответствуют обычно несколько файлов – один основной и несколько вспомогательных. Тонкости организации таблиц зависят от используемого формата (dBase, Paradox, InterBase, Microsoft Access и т.д.)

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

Индекс – поле, так же, как и ключ, специально выделенное в таблице, данные в котором, однако, могут повторяться. Они также служат для ускорения доступа и, кроме того, для сортировки и выборок.

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

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

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

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

• выполнена первая форма;
• любое неключевое поле однозначно идентифицируется ключевыми полями (фактически, требование наличия ключа)

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

• выполнена вторая форма
• неключевые поля должны однозначно идентифицироваться только ключевыми полями (это значит, что данные, не зависящие от ключа, должны быть вынесены в отдельную таблицу)

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

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

Способы доступа определяют, как технически производятся операции с записями. Способы доступа выбираются программистом во время разработки приложения. Навигационный способ основан на последовательной обработке нужных записей поодиночке. Он обычно используется для небольших локальных таблиц. Реляционный способ основан на обработке сразу набора записей с помощью SQL-запросов. Он используется для больших удалённых БД.

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

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