Важной составляющей последовательности разработки информационной системы является построение модели данных и информационно-логической модели предметной области.
Модель данных — совокупность структур данных и операций по их обработке. С помощью модели данных можно наглядно представить структуру объектов и установленные между ними связи. Для терминологии моделей данных характерны понятия «элемент данных» и «правила связывания». Элемент данных описывает любой набор данных, а правила связывания определяют алгоритмы взаимосвязи элементов данных. К настоящему времени разработано множество различных моделей данных, но на практике используется три основных. Выделяют иерархическую, сетевую и реляционную модели данных. Соответственно говорят об иерархических, сетевых и реляционных СУБД.
Иерархическая модель данных.
Иерархически организованные данные встречаются в повседневной жизни очень часто. Например, структура высшего учебного заведения — это многоуровневая иерархическая структура. Иерархическая (древовидная) БД состоит из упорядоченного набора элементов. В этой модели исходные элементы порождают другие элементы, причем эти элементы в свою очередь порождают следующие элементы. Каждый порожденный элемент имеет только один порождающий элемент.
Организационные структуры, списки материалов, оглавление в книгах, планы проектов и многие другие совокупности данных могут быть представлены в иерархическом виде. Автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя.
Основным недостатком данной модели является необходимость использования той иерархии, которая была заложена в основу БД при проектировании. Потребность в постоянной реорганизации данных (а часто невозможность этой реорганизации) привели к созданию более общей модели — сетевой.
Сетевая модель данных.
Сетевой подход к организации данных является расширением иерархического подхода. Данная модель отличается от иерархической тем, что каждый порожденный элемент может иметь более одного порождающего элемента.
Поскольку сетевая БД может представлять непосредственно все виды связей, присущих данным соответствующей организации, по этим данным можно перемещаться, исследовать и запрашивать их всевозможными способами, то есть сетевая модель не связана всего лишь одной иерархией. Однако для того чтобы составить запрос к сетевой БД, необходимо достаточно глубоко вникнуть в ее структуру (иметь под рукой схему этой БД) и выработать механизм навигации по базе данных, что является существенным недостатком этой модели БД.
Реляционная модель данных.
Основная идея реляционной модели данных заключается в том, чтобы представить любой набор данных в виде двумерной таблицы. В простейшем случае реляционная модель описывает единственную двумерную таблицу, но чаще всего эта модель описывает структуру и взаимоотношения между несколькими различными таблицами.
Итак, целью информационной системы является обработка данных об объектах реального мира, с учетом связей между объектами. В теории БД данные часто называют атрибутами, а объекты — сущностями. Объект, атрибут и связь — фундаментальные понятия И.С.
Объект (или сущность) — это нечто существующее и различимое, то есть объектом можно назвать то «нечто», для которого существуют название и способ отличать один подобный объект от другого. Например, каждая школа — это объект. Объектами являются также человек, класс в школе, фирма, сплав, химическое соединение и т. д. Объектами могут быть не только материальные предметы, но и более абстрактные понятия, отражающие реальный мир. Например, события, регионы, произведения искусства; книги (не как полиграфическая продукция, а как произведения), театральные постановки, кинофильмы; правовые нормы, философские теории и проч.
Атрибут (или данное) — это некоторый показатель, который характеризует некий объект и принимает для конкретного экземпляра объекта некоторое числовое, текстовое или иное значение. Информационная система оперирует наборами объектов, спроектированными применительно к данной предметной области, используя при этом конкретные значения атрибутов (данных) тех или иных объектах. Например, возьмем в качестве набора объектов классы в школе. Число учеников в классе — это данное, которое принимает числовое значение (у одного класса 28, у другого— 32). Название класса — это данное, принимающее текстовое значение (у одного — 10А, у другого — 9Б и т. д.).
Развитие реляционных баз данных началось в конце 60-х годов, когда появились первые работы, в которых обсуждались; возможности использования при проектировании баз данных привычных и естественных способов представления данных — так называемых табличных даталогических моделей.
Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э. Кодд, опубликовавший 6 (июня 1970 г. статью A Relational Model of Data for Large-Shared Data Banks (Реляционная модель данных для больших коллективных банков данных). В этой статье впервые был использован термин «реляционная модель данных. Теория реляционных баз данных, разработанная в 70-х годах в США доктором Э. Коддом, имеет под собой мощную математическую основу, описывающую правила эффективной организации данных. Разработанная Э. Коддом теоретическая база стала основой для разработки теории проектирования баз данных.
Э. Кодд, будучи математиком по образованию, предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он доказал, что любой набор данных можно представить в виде двумерных таблиц особого вида, известных в математике как «отношения».
Реляционной считается такая база данных, в которой все данные представлены для пользователя в виде прямоугольных таблиц значений данных, и все операции над базой данных сводятся к манипуляциям с таблицами.
Таблица состоит из столбцов (полей) и строк (записей); имеет имя, уникальное внутри базы данных. Таблица отражает тип объекта реального мира (сущность), а каждая ее строка— конкретный объект. Каждый столбец таблицы — это совокупность значений конкретного атрибута объекта. Значения выбираются из множества всех возможных значений атрибута объекта, которое называется доменом (domain).
В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементам данных. Если при вычислении логического условия относительно элемента данных в результате получено значение «истина», то этот элемент принадлежит домену. В простейшем случае домен определяется как допустимое потенциальное множество значений одного типа. Например, совокупность дат рождения всех сотрудников составляет «домен дат рождения», а имена всех сотрудников составляют «домен имен сотрудников». Домен дат рождения имеет тип данных, позволяющий хранить информацию о моментах времени, а домен имен сотрудников должен иметь символьный тип данных.
Если два значения берутся из одного и того же домена, то можно выполнять сравнение этих двух значений. Например, если два значения взяты из домена дат рождения, то можно сравнить их и определить, кто из сотрудников старше. Если же значения берутся из разных доменов, то их сравнение не допускается, так как, по всей вероятности, оно не имеет смысла. Например, из сравнения имени и даты рождения сотрудника ничего определенного не выйдет.
Каждый столбец (поле) имеет имя, которое обычно записывается в верхней части таблицы. При проектировании таблиц в рамках конкретной СУБД имеется возможность выбрать для каждого поля его тип, то есть определить набор правил по его отображению, а также определить те операции, которые можно выполнять над данными, хранящимися в этом поле. Наборы типов могут различаться у разных СУБД.
Имя поля должно быть уникальным в таблице, однако различные таблицы могут иметь поля с одинаковыми именами. Любая таблица должна иметь, по крайней мере, одно поле; поля расположены в таблице в соответствии с порядком следования их имен при ее создании. В отличие от полей, строки не имеют имен; порядок их следования в таблице не определен, а количество логически не ограничено.
Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции — среди них не существует «первой», «второй», «последней». Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key). Часто вводят искусственное поле, предназначенное для нумерации записей в таблице. Таким полем, например, может быть его порядковый, который сможет обеспечить уникальность каждой записи в таблице. Ключ должен обладать следующими свойствами.
Уникальностью. В каждый момент времени никакие два различных кортежа отношения не имеют одинакового значения для комбинации входящих в ключ атрибутов. То есть в таблице не может быть двух строк, имеющих одинаковый идентификационный номер или номер паспорта.
Минимальностью. Ни один из входящих в ключ атрибутов не может быть исключен из ключа без нарушения уникальности. Это означает, что не стоит создавать ключ, включающий и номер паспорта, и идентификационный номер. Достаточно использовать любой из этих атрибутов, чтобы однозначно идентифицировать кортеж. Не стоит также включать в ключ неуникальный атрибут, то есть запрещается использование в качестве ключа комбинации идентификационного номера и имени служащего. При исключении имени служащего из ключа все равно можно уникально идентифицировать каждую строку.
Каждое отношение имеет, по крайней мере, один возможный ключ, поскольку совокупность всех его атрибутов удовлетворяет условию уникальности — это следует из самого определения отношения.
Один из возможных ключей произвольно выбирается в качестве первичного ключа. Остальные возможные ключи, если они есть, принимаются за альтернативные ключи. Например, если в качестве первичного ключа выбрать идентификационный номер, то номер паспорта будет альтернативным ключом.
Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key).
При описании модели реляционной базы данных для одного и того же понятия часто употребляют различные термины, что зависит от уровня описания (теория или практика) и системы (Access, SQL Server, dBase). В табл.7.1. приведена сводная информация об используемых терминах.
Реляционные базы данных
Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных. То есть база данных представляет набор таблиц, необходимых для хранения всех данных. Таблицы реляционной базы данных логически связаны между собой.Требования к проектированию реляционной базы данных в общем виде можно свести к нескольким правилам.
Каждая таблица имеет уникальное в базе данных имя и состоит из однотипных строк.
Каждая таблица состоит из фиксированного числа столбцов и значений. В одном столбце строки не может быть сохранено более одного значения. Например, если есть таблица с информацией об авторе, дате издания, тираже и т. д., то в столбце с именем автора не может храниться более одной фамилии. Если книга написана двумя и более авторами, придется использовать дополнительные таблицы.
Ни в какой момент времени в таблице не найдется двух строк, дублирующих друг друга. Строки должны отличаться хотя бы одним значением, чтобы была возможность однозначно идентифицировать любую строку таблицы.
Каждому столбцу присваивается уникальное в пределах таблицы имя; для него устанавливается конкретный тип данных, чтобы в этом столбце размещались однородные значения (даты, фамилии, телефоны, денежные суммы и т. д.).
Полное информационное содержание базы данных представляется в виде явных значений самих данных, и такой метод представления является единственным. Например, связь между таблицами осуществляется на основе хранимых в соответствующих столбцах данных, а не на основе каких-либо указателей, искусственно определяющих связи.
При обработке данных можно свободно обращаться к любой строке или любому столбцу таблицы. Значения, хранимые в таблице, не накладывают никаких ограничений на очередность обращения к данным. Описание столбцов,
Нормализация и ее необходимость.
При проектировании структуры базы данных заказчик часто предоставляет разработчику описание форм и бланков, существующих в бумажном виде. Поэтому, прежде чем приступать к проектированию таблиц для БД, необходимо выяснить цели проектирования. К ним относятся:
- возможность хранить все необходимые данные в БД;
- исключение избыточности данных;
- необходимость свести количество хранимых таблиц к .минимуму.
При простом переносе полей бумажных форм в таблицы базы данных неизбежно возникнет ряд проблем — даже для простых двумерных структур приходится изменять состав полей
( В дальнейшем при проектировании базы данных эта универсальная таблица может быть разбита на несколько таблиц, имеющих более простую структуру и связанных друг с другом.
Нормализация таблиц — это формальный аппарат ограничений на формирование таблиц, описывающий разбиение таблиц на две или более частей и обеспечивающий применение лучших методов добавления, изменения и удаления данных; или еще проще — процесс представления данных в виде простых двумерных таблиц, который позволяет устранить дублирование этих данных и обеспечивает непротиворечивость хранимых в базе данных. Таким образом, окончательной целью нормализации является получение такого проекта базы данных, в котором любая часть информации хранится лишь в одном месте, то есть исключается избыточность информации. Это делается не столько с целью экономии места (в некоторых случаях нормализованные таблицы занимают больше места, чем ненормализованные), сколько для исключения возможности противоречий в хранимых данных. Если исходить из структуры данных, то нормализацией называется процесс превращения сетевой или иерархической структуры данных в реляционную.
Основой процесса нормализации является предложенный Е. Коддом в рамках реляционной теории аппарат, называемый нормализацией отношений. Им выделено три формы нормальных отношений, которые в дальнейшем были доработаны, и предложен механизм перехода от формы к форме, а кроме того было добавлено еще три специальных формы. Итого, существует шесть форм „ нормальных отношений. Но, как правило, необходимо и достаточно привести базу данных к третьей нормальной форме.
Таблица считается нормализованной на определенном уровне, когда она удовлетворяет условиям, накладываемым соответствующей формой нормализации. Процесс нормализации представляет собой последовательное изменение структуры таблиц до тех пор, пока она не будет удовлетворять требованиям последней формы нормализации. Существуют следующие шесть форм нормализации: О первая нормальная форма (First Normal Form, INF);
О вторая нормальная форма (Second Normal Form, 2NF);
О третья нормальная форма (Third Normal Form, 3NF);
О нормальная форма Бойса - Кодда (Brice - Codd Normal Form, BCNF);
О четвертая нормальная форма (fourth Normal Form, 4NF);
О пятая нормальная форма, или нормальная форма проекции-соединения (Fifth Normal Form, 5NF или PJ/NF).
При описании нормальных форм используется несколько понятий.
Функциональной зависимостью между полями A и В называется зависимость, при которой каждому значению А в любой момент времени соответствует единственное значение В из всех возможных. Примером функциональной зависимости может служить связь реки и моря, так как одна река впадает в единственное море и с течением времени эта связь не меняется.
Полной функциональной зависимостью между составным полем А и полем В называется зависимость, при которой поле В зависит функционально от поля А и не зависит функционально от любого подмножества поля А.
Многозначная функциональная зависимость. Поле А однозначно определяет поле В, если для каждого значения поля А существует хорошо определенное множество соответствующих значений поля В. Например, если рассматривать таблицу предметов и оценок учеников в школе, то поле с оценкой имеет хорошо определенное множество допустимых значений (1, 2, 3, 4, 5). Кроме того, количество предметов в школе также ограничено.
Транзитивная функциональная зависимость между полями А и С наблюдается в том случае, если поле В функционально зависит от поля А и поле С функционально зависит от поля В. В то же время не существует функциональной зависимости поля А от поля В.
Несколько полей взаимно независимы, если ни одно из них не является функционально зависимым от другого поля.
Неключевым полем таблицы называется каждое поле, не входящее в состав первичного ключа.
Первая нормальная форма
Таблица находится в первой нормальной форме тогда, когда она не содержит повторяющихся полей и составных значений полей (то есть каждое поле должно содержать одно значение, а не их комбинацию).
Вторая нормальная форма
Таблица находится во второй нормальной форме, если она удовлетворяет требованиям первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом, то есть любое не ключевое поле однозначно идентифицируется полным набором ключевых полей.
Итак, таблица, находящаяся во второй нормальной форме, должна удовлетворять следующим правилам:
- таблица должна содержать данные об одном типе объектов;
- каждая таблица должна содержать одно поле или несколько полей, образующих уникальный идентификатор (или первичный ключ) для каждой строки;
- все поля, не имеющие ключа, должны определяться полным уникальным идентификатором данной таблицы.
Если таблица имеет простой первичный ключ, состоящий только из одного
Третья нормальная форма
Таблица находится в третьей нормальной форме, если она удовлетворяет определению второй нормальной формы и ни одно из ее неключевых полей функционально не зависит от любого другого неключевого поля. Можно сказать, что таблица находится в третьей нормальной форме, если она находится во второй нормальной форме и каждое неключевое поле нетранзитивно зависит от первичного ключа.
Требование третьей нормальной формы сводится к тому, чтобы все нёключевые поля зависели только от первичного ключа и не зависели друг от друга. Другими словами, нужно иметь возможность изменять значение любого неключевого поля, не изменяя значения любого другого поля базы данных. Это требование исключает любое поле, значения в котором получаются как результат вычислений, использующих значения других полей.