double arrow

Информационная модель данных


Основы теории проектирования баз данных

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

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




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

Для понимания процесса построения информационной системы, рассмотрим ряд терминов, которые применяются при описании и представлении данных.

f Предметной областью называется часть реальной системы, представляющей интерес для данного исследования.

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

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

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



f Концептуальная модель представляет объекты и их взаимосвязи

без указания способов их физического хранения.

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

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

На практике встречается в основном два подхода к выбору состава и структуры предметной области.

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

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



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

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

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

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

f Логическая модель отражает логические связи между элементами

данных независимо от их содержания и среды хранения.

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

f Физическая модель, определяющая размещение данных,

методы доступа и технику индексирования, называется

внутренней моделью системы.

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

Рис 5.1.1 Уровни независимости модели

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

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

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

f Объектом называется элемент информационной системы, информацию о котором мы сохраняем. В реляционной теории баз данных объект называют сущностью.

Объект может быть реальным (человек, населенный пункт и т.д.) и абстрактным (например, изучаемый студентами курс). Например, в области учета успеваемости объектами могут служить: СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, ФАКУЛЬТЕТ, ПРЕДМЕТ. В области учета расхода горючего на автомобильный транспорт – АВТОМОБИЛИ, ВОДИТЕЛИ и т.д. Каждый объект обладает определенным набором свойств, которые запоминаются в информационной системе. При обработке данных часто приходится иметь дело с совокупностью однородных объектов, например, СТУДЕНТЫ и записывать информацию об одних и тех же свойствах для каждого их них.

f Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств.

Таким образом, для объектов одного класса набор свойств будет одинаков, хотя значения этих свойств для каждого объекта буду разными. Так, например, класс объектов АВТОМОБИЛИ будет иметь набор следующих характеристик (свойств) : Государственный номер, Марка автомобиля, Дата постановки на учет, Нормы расхода горючего, Стоимость и т.д. Каждый автомобиль будет иметь различные значения этих характеристик. Объекты и их свойства являются понятиями реального мира. В мире информации, существующем в представлении программиста, говорят об атрибутах объектов.

f Атрибут- это информационное свойств объекта. Каждый объект характеризуется рядом основных атрибутов.

Например, АВТОМОБИЛЬ характеризуется набором атрибутов, которые соответствуют свойствам этого же объекта (Государственный номер, Марка автомобиля, Дата постановки на учет, Нормы расхода горючего, Стоимость). Каждый атрибут в модели должен, иметь уникальное имя – идентификатор. Атрибут при реализации информационной модели на каком-либо носителе информации часто называют элементом данных, полем данных или просто полем. Связь между понятиями «Реальный мир», «Информация» и «Сохраняемые данные» можно отобразить следующей схемой (Рис 5.1.2)

 
 


Рис 5.1.2 Схема связи понятий.

f Таблица – это некоторая регулярная структура, состоящая из конечного набора однотипных записей.

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

f Значение данных представляет собой действительные данные, содержащиеся в каждом элементе данных.

Элемент данных МАРКА АВТОМОБИЛЯ может принимать значения «СТЗМ-32151», «ГАЗ-31029». В зависимости от того, как элементы описывают объект, их значения могут быть количественными, качественными, описательными. Информацию о некоторой предметной области можно представить с помощью нескольких объектов., каждый из которых описывается несколькими элементами данных. принимаемые элементами значения данных называются данными. Единичный набор значений, принимаемых элементами данных, называется экземпляром объекта. Объекты связываются между собой определенным образом. Соответствующая модель объектов с составляющими их элементами данных и взаимосвязями образуют концептуальную модель. Она дает общее представление о потоках данных в предметной области. Некоторые элементы данных обладают важным свойством для построения информационной модели. Например, если известно значение какого-то элемента данных объекта, то мы можем идентифицировать значения, которые принимают значения этого же объекта. Например, мы знаем ГОСУДАРСТВЕННЫЙ НОМЕР автомобиля «С 583 ГВ». Соответственно этому номеру мы можем узнать марку автомобиля, рабочий объем двигателя и т.д.

f Ключевым элементом данных называют такой элемент, по которому можно определить значения других элементов.

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

f Первичный ключ – это атрибут (или группа атрибутов), которые единственным образом идентифицируют каждую строку в таблице.

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

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

Например, объект «СТУДЕНТ» имеет атрибуты:

НОМЕР ЗАЧЕТНОЙ КНИЖКИ

ФАМИЛИЯ

ИМЯ

ОТЧЕСТВО.

Если предположить, что в ВУЗе не учатся полные тезки, то альтернативным ключом по отношению к атрибуту «НОМЕР ЗАЧЕТНОЙ КНИЖКИ» будет группа атрибутов «ФАМИЛИЯ», «ИМЯ», «ОТЧЕСТВО».

f Запись данных – это совокупность значений связанных элементов данных.

На рис 5.1.3 такими элементами данных являются Госномер, ТабНом, СпидНач, СпидКон, Дата

Путевой лист.

Госномер Табном. СпидНач СпидКон Дата
09-27 ССВ 05.06.00
21-42 ССВ 07.09.00
21-42 ССВ 12.12.00
17-94 ССЗ 15.05.00
09-27 ССВ 24.12.00
17-77 ССЗ 14.11.00
17-77 ССЗ 18.03.00
09-19 ССЭ 15.11.00
17-94 ССЗ 13.12.00
09-19ССЭ 18.09.00  

Рис 5.1.3

Например одна из записей – «09-27 ССВ 01 550 690 05.06.00» представляет собой значения, которые принимают элементы данных объекта. Записи хранятся на некотором носителе, в качестве которого может выступать документ, внешняя память ЭВМ и т.д.

f Тип данных характеризует вид хранящихся данных.

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

f Доменом называется набор значений элементов данных одного типа, отвечающий поставленным условиям.

На рис 5.1.4 представлена иерархия понятий в таблице «Справочник автомобилей»


Госномер Марка Норма Дата Постановки На учет
09-19 ССЭ СТЗМ-32151 15.10.99
09-27 ССВ ГАЗ-2417 12.12.98
13-12 ССВ ГАЗ-31029 10.10.97
17-77 ССЗ СТЗМ-32151 25.07.96
17-83 ССЗ ГАЗ-330210 24.07.96
17-94 ССЗ СТЗМ-32151 31.10.99
21-42 ССВ ГАЗ-2410 12.12.00

Рис 5.1.4

В общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Тип данных не позволяет записать недопустимое значение. Если вычисление этого логического выражения дает результат «истина», то элемент данных является элементом домена. В упрощенном виде понятие домена может характеризоваться как множество допустимых значений одного типа. Например, домен «ГосНом» определен на базовом типе строк символов. Однако, в число его значений могут входить только те строки, которые могут изображать табельный номер. Необходимо также отметить семантическую нагрузку домена: данные считаются сравнимыми только в том случае, если они относятся к одному домену. В нашем примере значения доменов «ГосНом» и «Марка» хотя и относятся к типу строк символов, не являются сравнимыми.

f Связь – это функциональная зависимость между сущностями (объектами).

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

¨ тип связи (идентифицирующая, не идентифицирующая, полная, неполная, неспецифическая связь);

¨ Родительская сущность;

¨ дочерняя (зависимая) сущность;

¨ мощность связи;

¨ допустимость пустых (NULL) значений

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

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

Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности.

f Представление – это сохраняемый в базе данных именованный запрос на выборку данных из одной или нескольких таблиц.

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

f Хранимые процедуры – это приложение(программа), объединяющее запросы и процедурную логику и хранящиеся в базе данных.

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

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

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

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

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







Сейчас читают про: