По модели данных По типу управляемой базы данных можно выделить иерархические СУБД. Под иерархической моделью данных понимается модель, объединяющая записи, хранимые в общей древовидной структуре с одним корневым типом записи, который имеет несколько подчиненных типов записи или не имеет совсем. Каждый подчиненный тип записи также может иметь несколько подчиненных типов или не иметь их совсем. Основной структурой, поддерживающей иерархическое представление информации, является дерево. Достоинствами иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархическая модель данных удобна для работы с иерархически упорядоченной информацией. Недостатком иерархической модели является ее громоздкость для обработки информации с достаточно сложными логическими связями, а также сложность понимания для обычного пользователя. Примеры: зарубежные системы IMS, PC/Focus, Team-Up и Data Edge, а также отечественные системы Ока, ИНЭС и МИРИС;

2)Предложение INSERT языка SQL. Вставка единственной записи. Вставка множества записей.

INSERT INTO "table_name" ("column1", "column2",..) VALUES ("value1", "value2",...); -добавление записей

Например: INSERT INTO Store_Information (store_name, Sales, Date) VALUES ('Los Angeles', 900, 'Jan-10-1999');

Или: INSERT INTO Store_Information (store_name, Sales, Date)

SELECT store_name, Sales, Date FROM Sales_Information WHERE Year(Date) = 1998 ; - добавление записей в ту строку, где столбец Year(Date) = 1998

3)Проектирование реляционных БД с использованием нормализации: первая, вторая и третья нормальные формы.процедуру нормализации можно охарактеризовать как процедуру разб. логически несвязанной информации на отдельные переменные отношения.Первая нормальная форма. Отношение R находится в первой нормальной форме (1НФ), если значения каждого его атрибута являются атомарными, т.е. такими значениями, которые не являются множеством значений или повторяющейся группой. В определении реляционной модели Кодда все отношения всегда находятся в 1НФ.

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

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

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

 

Вторая нормальная форма. Отношение R находится во второй нормальной форме (2НФ), если никакие неключевые атрибуты не являются функционально зависимыми лишь от части ключа. Каждый неключевой столбец в таблице должен уникально идентифицирся по первичному ключу Таким образом, 2НФ может оказаться нарушена только в том случае, когда ключ составной. Полная функциональная зависимость Функциональная зависимость R.X (r) R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X. Транзитивная функциональная зависимость Функциональная зависимость R.X -> R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимостиR.X -> R.Z и R.Z -> R.Y и отсутствует функциональная зависимость R.Z --> R.X.(При отсутствии последнего требования мы имели бы "неинтересные" транзитивные зависимости в любом отношении, обладающем несколькими ключами.) Неключевой атрибут Неключевым атрибутом называется любой атрибут отношения, не входящий в состав ключа (в частности, первичного). Взаимно независимые атрибуты Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других. Вторая нормальная форма (предполагается, что единственным ключом отношения является первичный ключ) Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа. Если допустить наличие нескольких ключей, то определение примет следующий вид: Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда оно находится в 1NF, и каждый неключевой атрибут полностью зависит от каждого ключа R.

Третья нормальная форма. Кроме удовлетворения требованиям второй нормальной формы, каждый неключевой столбец таблицы должен быть независимым от других неключевых столбцов.Третья нормальная форма. (определение дается в предположении существования единственного ключа.) Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Если отказаться от того ограничения, что отношение обладает единственным ключом, то определение 3NF примет следующую форму: Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 1NF, и каждый неключевой атрибут не является транзитивно зависимым от какого-либо ключа R. На практике третья нормальная форма схем отношений достаточна в большинстве случаев, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Однако иногда полезно продолжить процесс нормализации.

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

Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 37 - Сетевые системы (системы, реализующие сетевую модель данных).
Часть 38 - 2)Понятие индекса. Предложения языка SQL CREATE INDEX и DROP INDEX. Параметр UNIQUE.
Часть 39 - Иерархические СУБД.
Часть 40 - Представления. Определение представления. SQL предложения CREATE VIEW и DROP VIEW. Особенности операций
Часть 41 - Понятие центра обработки данных (ЦОД). Назначение ЦОД. Структура и основные технические элементы ЦОД.
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и