Характеристика основных моделей информации

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

- каждый элемент таблицы - один  элемент данных; повторяющиеся

группы отсутствуют;

- все столбцы в таблице однородные, т.е. все элементы в столбце

имеют одинаковый тип (числовой, символьный и т.д.) и длину;

- каждый столбец имеет уникальное  имя;

- одинаковые строки в таблице  отсутствуют;

- порядок следования строк и  столбцов может быть произвольным.

Таблица такого рода называется отношением.

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

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

                             

                  Некоторые операции реляционной алгебры                 

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

Проектирование баз данных традиционно  считалось очень трудной задачей. Реляционная технология значительно  упрощает эту задачу. Разделением  логического и физического уровней  системы она упрощает процесс отображения "уровня реального мира", в структуру, которую система может прямо поддерживать. Поскольку реляционная структура сама по себе концептуально проста, она позволяет реализовывать небольшие и/или простые (и поэтому легкие для создания) базы данных, такие как персональные, сама возможность реализации которых никогда даже бы не рассматривалась в старых более сложных системах. Теория и дисциплина нормализации может помочь, показывая, что случается, если отношения не структурированы естественным образом. Реляционная модель данных особенно удобна для использования в базах данных распределенной архитектуры - она позволяет получать доступ к любым информационным элементам, хранящимся в узлах сети ЭВМ. Необходимо обратить особое внимание на высокоуровневый аспект реляционного подхода, который состоит во множественной обработке записей. Благодаря этому значительно возрастает потенциал реляционного подхода, который не может быть достигнут при обработке по одной записи и, прежде всего, это касается оптимизации.

Данная модель позволяет определять:

- операции по запоминанию и  поиску данных;

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

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

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

- поддерживает реляционную структуру данных;

- реализует по крайней мере операции селекции, проекции и соединения отношений.

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

Суть реляционной СУБД можно  пояснить на следующем простом примере.

    

Файл авторов публикаций БД
№ п/п		Автор	Адрес	Телефон	Число публ.
		.	.	.	.
6		Купцов	Москва	635-6078	140
7		Бухтяк	Томск	637-2050	140
8		Терпугов	Томск	538-584	250

 

    

Файл публикаций РБД
№ п/п		Назв. Публикации	Тип публ.	Дата	Объём в п. л.
6		Основы .	Статья	2.95	2.5
7		Проблема .	Книга	3.97	35
8		Теория .	Статья	6.96	3.8
		.	.	.	.

 

       В некоторой реляционной БД (РБД) имеются два файла авторов и публикаций, каждый из которых содержит определенное число записей, состоящих из фиксированного числа полей (соответственно 4 и 5), представляющих данные по соответствующим элементам предметной области. Можно сказать, что определены два отношения (фaйла), имеющие общий элемент — значения поля № п/п. Операции реляционной алгебры могут объединять два типа записей по этому общему элементу. Например, в результате соединения запись Бухтяк может представится в следующем виде:

Бухтяк<Томск><637-2050><40><Основы...><статья><2.95><2.5>.... т.е. к сведениям об авторе добавляются сведения обо всех его публикациях, имеющихся в РБД.

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

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

       Но выявлены и недостатки рассмотренной модели баз данных:

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

- высокая трудоемкость манипулирования информацией и изменения

связей.

 

 2.4. Информационно-логическая модель данных.                                                                        

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

    

 

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

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

внешняя модели.

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

     Внутренний уровень отображает требуемую организацию данных в среде

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

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

 

ЗАКЛЮЧЕНИЕ.

       Пользователями БД являются четыре основные категории потребителей ее информации и/или поставщиков информации для нее:

- конечные пользователи,

- программисты и системные аналитики,

- персонал поддержки БД в  актуальном состоянии,

- администратор БД.

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

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