Управление данными. Громов Ю.Ю - 19 стр.

UptoLike

ВУЗ: 

ТГТУ | Тамбов

Составители: 

Рубрика: 

ной области выбрать учёт товаров на складе, то понятия «накладная» и «счёт-фактура» являются суще-
ственно важными понятиями, а то, что сотрудница, принимающая накладные, имеет двоих детей, – это
для учёта товаров неважно. Однако с точки зрения отдела кадров данные о наличии детей являются су-
щественно важными. Таким образом, важность данных зависит от выбора предметной области.
Модель предметной области
. Модель предметной области – это наши знания о предметной области.
Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при
помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной
области, наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт показывает,
что текстовый способ представления модели предметной области крайне неэффективен. Гораздо более
информативными и полезными при разработке баз данных являются описания предметной области, вы-
полненные при помощи специализированных графических нотаций. Имеется большое количество мето-
дик описания предметной области. Из наиболее известных можно назвать методику структурного ана-
лиза SADT и основанную на нём IDEF0, диаграммы потоков данных Гейна-Сарсона, методику объект-
но-ориентированного анализа UML и др. Модель предметной области описывает скорее процессы, про-
исходящие в предметной области, и данные, используемые этими процессами. От того, насколько пра-
вильно смоделирована предметная область, зависит успех дальнейшей разработки приложений.
Логическая модель данных
. На следующем, более низком уровне находится логическая модель
данных предметной области. Логическая модель описывает понятия предметной области, их взаимо-
связь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий – «сотруд-
ник», «отдел», «проект», «зарплата». Примеры взаимосвязей между понятиями – «сотрудник числится
ровно в одном отделе», «сотрудник может выполнять несколько проектов», «над одним проектом может
работать несколько сотрудников». Примеры ограничений – «возраст сотрудника не менее 16 и не более
60 лет».
Логическая модель данных является начальным прототипом будущей базы данных. Логическая мо-
дель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того,
логическая модель данных необязательно должна быть выражена средствами именно реляционной мо-
дели данных. Основным средством разработки логической модели данных в настоящий момент являют-
ся различные варианты
ER-диаграмм
(
Entity-Relationship
,
диаграммы сущность-связь
). Одну и ту же ER-
модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархиче-
ских и сетевых СУБД, или в постреляционную модель данных. Однако, так как мы рассматриваем
именно реляционные СУБД, можно считать, что логическая модель данных для нас формулируется в
терминах реляционной модели данных.
Решения, принятые на предыдущем уровне, при разработке модели предметной области определя-
ют некоторые границы, в пределах которых можно развивать логическую модель данных, в пределах же
этих границ можно принимать различные решения. Например, модель предметной области складского
учёта содержит понятия «склад», «накладная», «товар». При разработке соответствующей реляционной
модели эти термины обязательно должны быть использованы, но различных способов реализации тут
много – можно создать одно отношение, в котором будут присутствовать в качестве атрибутов «склад»,
«накладная», «товар», а можно создать три отдельных отношения, по одному на каждое понятие.
При разработке логической модели данных возникают вопросы: хорошо ли спроектированы отно-
шения? Правильно ли они отражают модель предметной области, а следовательно и саму предметную
область?
Физическая модель данных
. На ещё более низком уровне находится физическая модель данных.
Физическая модель данных описывает данные средствами конкретной СУБД. Мы будем считать, что
физическая модель данных реализована средствами именно реляционной СУБД, хотя, как уже сказано
выше, это необязательно. Отношения, разработанные на стадии формирования логической модели дан-
ных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов соз-
даются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.
Ограничения, имеющиеся в логической модели данных, реализуются различными средствами
СУБД, например, при помощи индексов, декларативных ограничений целостности, триггеров, храни-
мых процедур. При этом решения, принятые на уровне логического моделирования, определяют неко-
торые границы, в пределах которых можно развивать физическую модель данных. Точно так же в пре-
делах этих границ можно принимать различные решения. Например, отношения, содержащиеся в логи-
ческой модели данных, должны быть преобразованы в таблицы, но для каждой таблицы можно допол-

Страницы