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

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

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

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

Проблемы, которые должна решить нормализации:

Проблемы эти заключаются в том, что даже для простых двухмерных структур приходится изменять состав полей. В таблицу должны включаются только те поля, значения которых зависит от первичного ключа. В противном случае появляется возможность утери информации. Например, в таблицу «Вкладчики» нельзя включать поле «% по вкладу». При изменении значения % по вкладу, придется менять значение в каждой записи. Однако важнее другое: повторяя многократно одни и те же данные, мы не только переделаем массу лишней работы, но и неминуемо ошибемся. Поэтому следует стремиться к исключению из таблицы полей, которые не связаны непосредственно с первичным ключом таблицы. Для этого, помимо оперативной, можно создать несколько справочных таблиц. Оперативная таблица меняется часто, а справочники – редко, их легко выправить раз и навсегда, внося в дальнейшем лишь небольшие изменения.

Информация, разная по объему для каждого экземпляра объекта.

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

Большая часть этих полей в конкретных записях будет «пустой».

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

Связь таблиц: главная и подчиненная таблицы.

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

• Пара таблиц Вкладчики и Приходный ордер. Общее поле – Номер счета.

• В таблице Вкладчики поле Номер счета является первичным ключом, следовательно: Вкладчики– главная таблица; Приходный ордер - подчиненная таблица (таблица деталей).

Первичный ключ Номер счета+Дата прихода.

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

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

Отношение «Много-ко-Многим) - возникает между двумя таблицами в тех случаях, когда:

• одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

• одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.

Реляционная модель данных состоит из трех частей:

• Структурной части;

• Целостной части;

• Манипуляционной части.

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

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

Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное исчисление.

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

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

Преимуществами объектных СУБД модно считать:

• объектные СУБД – открытые системы. Несложно добавить новый тип данных;

Большинство производителей ООБД предоставляют визуальные средства создания прикладных программ ОСУБД. Если раньше созданием прикладных программ для ОСУБД занимались специалисты в C++, Smaltalk, то теперь использовать ООБД стало намного проще

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

Традиционные области применения ОСУБД – САПР, моделирование, мультимедиа. ОСУБД широко используются в телекоммуникациях, различных аспектах автоматизации предприятия, издательском деле, геоинформационных проектах.

Проектирование БД.

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

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

Инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет "читаться". Общепринятым стало сокращенное название такой модели - ER-модель

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

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

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

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

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

Большинство современных CASE-средств содержит инструментальные средства для описания данных в формализме этой модели.

В основе ER-модели лежат следующие базовые понятия.

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

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

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

Может --------------

Должен _______________