Построение инфологической модели

Построение инфологической модели

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

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

Атрибут — поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей.

Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность.

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

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

При проектировании информационной базы АРМ инженера по охране труда были выделены следующие типы сущностей:

Рис. 3.1 — Инфологическая модель данных

Построение даталогической модели

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

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

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

Описание концептуальной схемы БД в терминах выбранной СУБД.

Описание внешних моделей в терминах выбранной СУБД.

Описание декларативных правил поддержки целостности базы данных.

Описание процедур поддержки семантической целостности базы данных.

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

Проектирование схемы БД может быть выполнено двумя путями:

— путем декомпозиции (разбиения), когда исходное множество отношений, входящих в схему БД заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений;

— путем синтеза, то есть путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.

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

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

первая нормальная форма (1NF);

вторая нормальная форма (2NF);

третья нормальная форма (3NF);

нормальная форма Бойса-Кодда (BCNF);

четвертая нормальная форма (4NF);

пятая нормальная форма, или форма проекции-соединения (5NF или PJNF).

Основные свойства нормальных форм:

каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей;

при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

Главное отличие даталогической модели от инфологической состоит в том, что инфологическая модель хранит в себе всю информацию о предметной области, но она не привязана к определенной СУБД.

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

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

Рис. 3.2 — Даталогическая модель

Этап 2. Построение инфологической модели

Инфологические модель — (сокращение отинформационно-логическая модель, т.е. логика управления информацией). Инфологические модели часто называют семантическими моделями.

Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером ( Hammer ) и Мак-Леоном ( McLeon ) в 1981 году, функциональную модель данных Шипмана ( Shipman ), также созданную в 1981 году, модель «сущность—связь», предложенную Ченом ( Chen ) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена «сущность—связь», или «Entity Relationship», стала фактическим стандартом при инфологическом моделировании баз данных.

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

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

Модель Сущность-Связь (ER — Entity-relationship)

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

Структура данных может быть описана:

1. В виде исходного текста на ЯОД;

2. В графовой форме;

3. В табличной форме.

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

Модель «СС» – это неформальная модель предметной области, которая используется на этапе инфологического проектирования БД. Существует несколько подходов к построению модели «СС».

Общим для всех подходов является использование 3-х конструктивных элементов:

· сущность,

· атрибут,

· связь.

Составляющая «время» в явном виде отсутствует, но ее можно отразить с помощью атрибутов (напр. «дата рождения»).

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

Атрибут – поименованная характеристика сущности, которая принимает значение из некоторого множества значений (домена). В модели атрибут выступает в качестве средства, с помощью которого моделируются свойства сущностей. Чтобы задать атрибут, необходимо:

· присвоить ему наименование;

· привести смысловое описание;

· определить множество возможных значений;

· указать, для чего он используется.

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

Связи выступают в модели в качестве средства, с помощью которого представляются отношения между сущностями, имеющими место в предметной области. («отношение» — математич. термин).

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

Различают бинарные связи, тернарные связи (3 сущности), в общем случае n-арные связи. Чаще всего встречаются бинарные связи. В используемой нотации для бинарных связей необходимо на схемах выставлять стрелки на концах дуг и указывать коэффициенты, характеризующие отношение, а для многомерных связей стрелки и коэффициенты не ставятся. Типы бинарных связей: 1:1; 1:M; M:1; M:N.

Связи могут иметь свой атрибут. Тогда связь выполняет как бы функцию сущности, т.е. тип отношения рассматривается как тип сущности. Напр.: возьмем отношение ДЕТАЛЬ_Х_РАЗМЕЩЕ-НА_НА_СКЛАДЕ_Y, оно же может рассматриваться как тип сущности, о которой мы хотим хранить к.-л. информацию (количество деталей на складе).

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

При этом используют следующие обозначения:

· сущности – прямоугольниками;

· атрибуты – овалами, при этом соединяют их с соответствующими сущностями ненаправленными дугами, идентифицирующие атрибуты подчеркиваются;

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

Правила при моделировании:

1. Используются только 3 типа конструктивных элементов (сущность, атрибут, связь);

2. В отдельном проектном представлении каждый элемент проекта моделируется только одним конструктивным элементом.

При моделировании предметной области проектировщик:

· — разбивает ее на ряд локальных областей;

· — моделирует каждое локальное представление (по 6-7 сущностей);

· — объединяет локальные представления.

Пример

Рисунок 4 Графовая форма представления схемы БД

CASE — нотация ER-диаграммы

тип записи (группы) изображается прямоугольником, над верх. лев. углом кот. ставится название. Внутри прямоугольника могут быть имена элементов данных, агрегированных в группу;

Между сущностями могут быть установлены связи — бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности.

Например, если у нас есть связь между сущностью «Студент» и сущностью «Преподаватель» и эта связь — руководство дипломными проектами, то каждый студент имеет только одного руководителя, но один и тот же преподаватель может руководить множеством студентов-дипломников. Поэтому это будет связь «один-ко-многим» (1:М), один со стороны «Преподаватель» и многие со стороны «Студент»

Рисунок 5 . Пример отношения «один-ко-многим» при связывании

сущностей «Студент» и «Преподователь»

Множественность изображается путем разделения линии связи на 3.

Связь имеет общее имя «Дипломное проектирование» и имеет имена ролей со стороны обеих сущностей. Со стороны студента эта роль называется «Пишет диплом под руководством», со стороны преподавателя эта связь называется «Руководит».

Графическая интерпретация связи позволяет сразу прочитать смысл взаимосвязи между сущностями, она наглядна и легко интерпретируема. Связи делятся на три типа по множественности: один-к-одному (1:1), один-ко-многим (1:M), многие-ко-многим (M:M). Связь один-к-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности.

Связь 1: M означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.

Связь «один-к-одному» (1:1) означает, что один экземпляр одной сущности связан только с одним экземпляром другой сущности, а связь «многие-ко-многим» (M:M) означает, что один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот, один экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности.

Например, если мы рассмотрим связь типа «Изучает» между сущностями «Студент» и «Дисциплина», то это связь типа «многие-ко-многим» (M:M), потому что каждый студент может изучать несколько дисциплин, но и каждая дисциплина изучается множеством студентов. Такая связь изображена на рис.6.

· Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. Например, между двумя сущностями «Студент» и «Преподаватель» можно установить две смысловые связи, одна — рассмотренная уже ранее «Дипломное проектирование», а вторая может быть условно названа «Лекции», и она определяет, лекции каких преподавателей слушает данный студент и каким студентам данный преподаватель читает лекции. Ясно, что это связь типа многие-ко-многим.Пример этих связей приведен на рис. 6.

Рис. 6.Пример моделирования связи «многие-ко-многим»

· Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной — если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны.Обязательность связи тоже по-разному обозначается в разных нотациях. Здесь необязательность связи обозначается пустым кружочком на конце связи, а обязательность перпендикулярной линией, перечеркивающей связь. И эта нотация имеет простую интерпретацию. Кружочек означает, что ни один экземпляр не может участвовать в этой связи. А перпендикуляр интерпретируется как то, что по крайней мере один экземпляр сущности участвует в этой связи. Рассмотрим для этого ранее приведенный пример связи «Дипломное проектирование». На нашем рисунке эта связь интерпретируется как необязательная с двух сторон. Но ведь на самом деле каждый студент, который пишет диплом, должен иметь своего руководителя дипломного проектирования, но, с другой стороны, не каждый преподаватель должен вести дипломное проектирование.

·

Рис. 7.Пример обязательной и необязательной связи между сущностями

Кроме того, в ER-модели допускается принцип категоризации сущностей. Это значит, что, как и в объектно-ориентированных языках программирования, вводится понятие подтипа сущности, то есть сущность может быть представлена в виде двух или более своих подтипов — сущностей, каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне. Все подтипы одной сущности рассматриваются как взаимоисключающие, и при разделении сущности на подтипы она должна быть представлена в виде полного набора взаимоисключающих подтипов. Если на уровне анализа не удается выявить полный перечень подтипов, то вводится специальный подтип, называемый условно ПРОЧИЕ, который в дальнейшем может быть уточнен. В реальных системах бывает достаточно ввести подтипизацию на двух-трех уровнях.

Сущность, на основе которой строятся подтипы, называется супертипом.Любой экземпляр супертипа должен относиться к конкретному подтипу. Для графического изображения принципа категоризации или типизации сущности вводится специальный графический элемент, называемый узел-дискриминатор, он изображается в виде полукруга, выпуклой стороной обращенного к суперсущности. Эта сторона соединяется направленной стрелкой с суперсущностью, а к диаметру этого круга стрелками подсоединяются подтипы данной сущности (см. рис. 8).

Рис. 8.Диаграмма подтипов сущности ТЕСТ

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

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

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

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

Между сущностями «Книги» и «Экземпляры» существует связь «один-ко-многим» (1:М), обязательная с двух сторон. Чем определяется данный тип связи? Мы можем предположить, что каждая книга может присутствовать в библиотеке в нескольких экземплярах, поэтому связь «один-ко-многим». При этом если в библиотеке нет ни одного экземпляра данной книги, то мы не будем хранить ее описание, поэтому если книга описана в сущности «Книги», то по крайней мере один экземпляр этой книги присутствует в библиотеке. Это означает, что со стороны книги связь обязательная. Что касается сущности «Экземпляры», то не может существовать в библиотеке ни одного экземпляра, который бы не относился к конкретной книге, поэтому и со стороны «Экземпляры» связь тоже обязательная.

Теперь нам необходимо определить, как в нашей системе будет представлен читатель. Естественно предложить ввести для этого сущность «Читатели», каждый экземпляр которой будет соответствовать конкретному читателю. В библиотеке каждому читателю присваивается уникальный номер читательского билета, который будет однозначно идентифицировать нашего читателя. Номер читательского билета будет ключевым атрибутом сущности «Читатели». Кроме того, в сущности «Читатели» должны присутствовать дополнительные атрибуты, которые требуются для решения поставленных задач, этими атрибутами будут: «Фамилия Имя Отчество», «Адрес читателя», «Телефон домашний» и «Телефон рабочий». Почему мы ввели два отдельных атрибута под телефоны? Потому что надо в разное время звонить по этим телефонам, чтобы застать читателя, поэтому администрации библиотеки будет важно знать, к какому типу относится данный телефон. В описании нашей предметной области существует ограничение на возраст наших читателей, поэтому в сущности «Читатели» надо ввести обязательный атрибут «Дата рождения», который позволит нам контролировать возраст наших читателей.

Из описания предметной области мы знаем, что каждый читатель может держать на руках несколько экземпляров книг. Для отражения этой ситуации нам надо провести связь между сущностями «Читатели» и «Экземпляры». А почему не между сущностями «Читатели» и «Книги»? Потому что читатель берет из библиотеки конкретный экземпляр конкретной книги, а не просто книгу. А как же узнать, какая книга у данного читателя? А это можно будет узнать по дополнительной связи между сущностями «Экземпляры» и «Книги», и эта связь каждому экземпляру ставит в соответствие одну книгу, поэтому мы в любой момент можем однозначно определить, какие книги находятся на руках у читателя, хотя связываем с читателем только инвентарные номера взятых книг. Между сущностями «Читатели» и «Экземпляры» установлена связь «один-ко-многим», и при этом она не обязательная с двух сторон. Читатель в данный момент может не держать ни одной книги на руках, а с другой стороны, данный экземпляр книги может не находиться ни у одного читателя, а просто стоять на полке в библиотеке.

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

Из описания предметной области нам известно, что каждая книга может содержать сведения из нескольких областей знаний, а с другой стороны, из практики известно, что в библиотеке может присутствовать множество книг, относящихся к одной и той же области знаний, поэтому нам необходимо установить между сущностями «Системный каталог» и «Книги» связь «многие-ко-многим», обязательную с двух сторон. Действительно, в системном каталоге не должно присутствовать такой области знаний, сведения по которой не представлены ни в одной книге нашей библиотеки, противное было бы бессмысленно. И обратно, каждая книга должна быть отнесена к одной или нескольким областям знаний для того, чтобы читатель мог ее быстрее найти.

Инфологическая модель предметной области «Библиотека» представлена на рис 9.

Рис. 9.Инфологическая модель «Библиотека»

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

ДАТАЛОГИЧЕСКИЕ МОДЕЛИ

Даталогические модели данных — трансформированная фонетическая калька от data-logic model, т.е. логика управления данными. Более корректно было бы произносить «дейтологическая модель», однако такое произношение в русском языке не принято. Так как в названии мы дважды произносим слова «данные» — как фонетическая калька от «data», и в русском варианте — «данные», иногда эту модель называют без повторения этого слова — «Логическая модель данных».

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

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

1.1. Модели, основанные на языках разметки документов, связаны прежде всего со стан­дартным общим языком разметки — SGML (Standart Generalised Markup Language), который был утвержден ISO в качестве стандарта еще в 80-х годах. Этот язык пред­назначен для создания других языков разметки, он определяет допустимый набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. С помощью SGML можно описывать структурированные данные, организовывать информацию, содержа­щуюся в документах, представлять эту информацию в некотором стандартизованном формате. Но ввиду некоторой своей сложности SGML использовался в основном для описания синтаксиса других языков (наиболее известным из которых является HTML), и немногие приложения работали с SGML-документами напрямую. Ему на смену был предложен новый язык гипертекстовой разметки, мощный, гибкий и, одновременно с этим, удобный язык XML.

XML (Extensible Markup Language) — это язык разметки, описывающий целый класс объектов данных, называемых XML-документами. Он используется в качестве средства для описания грамматики других языков и контроля за правильностью составления документов. То есть сам по себе XML не содержит никаких тегов, предназначенных для разметки, он просто определяет порядок их создания.

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

1.3. Дескрипторные модели — самые простые из документальных моделей, они широко использовались на ранних стадиях использования документальных баз данных.

В этих моделях каждому документу соответствует дескриптор — описатель. Этот дескриптор описывает документ в соответствии с теми характеристиками, которые требуются для работы с документами в разрабатываемой документальной БД.

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

Дата добавления: 2016-11-23; просмотров: 2836 | Нарушение авторских прав

Рекомендуемый контект:

Похожая информация:

Поиск на сайте:

Построение инфологической модели

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

К стержневым сущностям можно отнести:

  1. Создатели (Код создателя, Создатель).
    Эта сущность отводится для хранения сведений об основных людях, принимавших участие в подготовке рукописи издания (авторах, составителях, титульных редакторах, переводчиках и художниках). Такое объединение допустимо, так как данные о разных создателях выбираются из одного домена (фамилия и имена) и исключает дублирование данных (один и тот же человек может играть разные роли в подготовке разных изданий). Например, С.Я.Маршак писал стихи (Сказка о глупом мышонке) и пьесы (Двенадцать месяцев), переводил Дж.Байрона, Р.Бернса, Г.Гейне и составлял сборники стихов.
    Так как фамилия и имена (инициалы) создателя могут быть достаточно громоздкими (М.Е. Салтыков-Щедрин, Франсуа Рене де Шатобриан, Остен Жюль Жан-Батист Ипполит и т.п.) и будут многократно встречаться в разных изданиях, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут «Код_создателя», который будет автоматически наращиваться на единицу при вводе в базу данных нового автора, переводчика или другого создателя.
    Аналогично создаются: Код_издательства, Код_заглавия, Вид_ издания, Код_характера, Код_языка, Номер_билета, Номер_пере- плета, Код_места и Код_издания, замещающие от одного до девяти атрибутов.
  2. Издательства (Код_издательства, Название, Город).
  3. Заглавия (Код_заглавия, Заглавие).
    Выделение этой сущности позволит сократить объем данных и снизить вероятность возникновения противоречивости (исключается необходимость ввода длинных текстовых названий для различных томов собраний сочинений, повторных изданий, учебников и т.п.).
  4. Вид_издания (Вид_издания, Название_вида).
  5. Характеры (Код_характера, Характер_переиздания).
  6. Языки (Код_языка, Язык, Сокращение).
    Кроме названия языка хранится его общепринятое сокращение (англ., исп., нем., фр.), если оно существует.
  7. Места (Код_места, Номер_комнаты, Номер_стеллажа, Номер_ полки).
    Один из кодов этой сущности (например, «-1») отведен для описания обобщенного места, находящегося за стенами хранилища книг (издание выдано читателю, временно передано другой библиотеке или организации).
  8. Читатели (Номер_билета, Фамилия, Имя, Отчество, Адрес, Телефон).

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

Стержневые сущности и обозначения связаны между собой ассоциациями:

И, наконец, для уменьшения объема часто используемого обозначения «Издания» из него выделена характеристика:

  1. Аннотации (Код_издания, Аннотация) {Издание}.

Рис. 5.2. Инфологическая модель базы данных «Библиотека», построенная с помощью языка «Таблицы-связи»

Проектирование базы данных

В соответствие с процедурой проектирования (п. 4.4) каждая из полученных сущностей должна быть представлена базовой таблицей. Первый вариант этих таблиц описывается так:

СОЗДАТЬ ТАБЛИЦУ Создатели *( Стержневая сущность ) ПЕРВИЧНЫЙ КЛЮЧ ( Код_создат ) ПОЛЯ ( Код_создат Целое, Фам_ИО Текст 30 );СОЗДАТЬ ТАБЛИЦУ Издательства *( Стержневая сущность ) ПЕРВИЧНЫЙ КЛЮЧ ( Код_издательства ) ПОЛЯ ( Код_издательства Целое, Название Текст 40, Город Текст 25 );СОЗДАТЬ ТАБЛИЦУ Заглавия *( Стержневая сущность ) ПЕРВИЧНЫЙ КЛЮЧ ( Код_заглавия ) ПОЛЯ ( Код_заглавия Целое, Заглавие Запись );СОЗДАТЬ ТАБЛИЦУ Вид_издания *( Стержневая сущность ) ПЕРВИЧНЫЙ КЛЮЧ ( Вид_издания ) ПОЛЯ ( Вид_издания Целое, Название_вида Текст 16);СОЗДАТЬ ТАБЛИЦУ Характеры *( Стержневая сущность ) ПЕРВИЧНЫЙ КЛЮЧ ( Код_характера ) ПОЛЯ ( Код_характера Целое, Характер_переиздания Текст 16 );СОЗДАТЬ ТАБЛИЦУ Языки *( Стержневая сущность ) ПЕРВИЧНЫЙ КЛЮЧ ( Код_языка ) ПОЛЯ ( Код_языка Целое, Язык Текст 16, Сокращение Текст 6 );СОЗДАТЬ ТАБЛИЦУ Места *( Стержневая сущность ) ПЕРВИЧНЫЙ КЛЮЧ ( Код_места ) ПОЛЯ ( Код_места Целое, Номер_комнаты Целое, Номер_стелажа Целое, Номер_полки Целое );СОЗДАТЬ ТАБЛИЦУ Читатели *( Стержневая сущность ) ПЕРВИЧНЫЙ КЛЮЧ ( Ном_билета ) ПОЛЯ ( Ном_билета Целое, Фамилия Текст 20, Имя Текст 16, Отчество Текст 20, Адрес Текст 60, Телефон Текст 9 );СОЗДАТЬ ТАБЛИЦУ Издание *( Обозначение ) ПЕРВИЧНЫЙ КЛЮЧ ( Код_издания ) ВНЕШНИЙ КЛЮЧ ( Код_заглавия ИЗ Заглавия NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Заглавия ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Заглавия.Код_заглавия ОГРАНИЧИВАЕТСЯ) ВНЕШНИЙ КЛЮЧ ( Вид_издания ИЗ Вид_издания NULL-значения ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Вид_издания ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Вид_издания.Вид_издания КАСКАДИРУЕТСЯ) ВНЕШНИЙ КЛЮЧ ( Код_издательства ИЗ Издательства NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Издательства ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Издательства.Код_издательства КАСКАДИРУЕТСЯ) ПОЛЯ ( Код_издания Целое, Код_заглавия Целое, Вид_издания Текст 16, Номер_тома Целое, Авторский_знак Текст 3, Библиотечн_шифр Текст 12, Повторность Целое, Код_издательст- ва Целое, Год_издания Целое ) ОГРАНИЧЕНИЯ ( 1. Значения полей Код_заглавия, Вид_издания и Код_издательства должны принадлежать набору значений соответствующих полей таблиц Заглавия, Вид_издания и Издательства; при нарушении вывод сообщения «Такого заглавия нет», «Такого вида издания нет» или «Такого издательства нет». );СОЗДАТЬ ТАБЛИЦУ Переплеты *( Обозначение ) ПЕРВИЧНЫЙ КЛЮЧ ( Номер_переплета ) ВНЕШНИЙ КЛЮЧ ( Код_издания ИЗ Издания NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Издания ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Издания.Код_издания КАСКАДИРУЕТСЯ) ПОЛЯ ( Номер_переплета Целое, Код_издания Целое, Цена Деньги, Дата_приобретения Дата ) ОГРАНИЧЕНИЯ ( Значения поля Код_издания должны принадлежать набору значений соответствующего поля таблицы Издания; при нарушении вывод сообщения «Такого издания нет» );СОЗДАТЬ ТАБЛИЦУ Аннотации *( Характеризует Издания ) ПЕРВИЧНЫЙ КЛЮЧ ( Код_издания ) ВНЕШНИЙ КЛЮЧ ( Код_издания ИЗ Издания NULL-значения ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Издания ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Издания.Код_издания КАСКАДИРУЕТСЯ) ПОЛЯ ( Код_издания Целое, Аннотация Запись ) ОГРАНИЧЕНИЯ ( Значения поля Код_издания должны принадлежать набору значений соответствующего поля таблицы Издания; при нарушении вывод сообщения «Такого издания нет» );СОЗДАТЬ ТАБЛИЦУ Авторы *( Связывает Создатели и Издания ) ПЕРВИЧНЫЙ КЛЮЧ ( Код_создателя, Код_издания ) ВНЕШНИЙ КЛЮЧ ( Код_создателя ИЗ Создатели NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Создатели ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Создатели.Код_создателя КАСКАДИРУЕТСЯ) ВНЕШНИЙ КЛЮЧ ( Код_издания ИЗ Издания NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Издания ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Издания.Код_издания КАСКАДИРУЕТСЯ) ПОЛЯ ( Код_создателя Целое, Код_издания Целое ) ОГРАНИЧЕНИЯ ( Значения полей Код_создателя и Код_издания должны принадлежать набору значений соответствующих полей таблиц Создатели и Издание; при нарушении вывод сообщения «Такого автора нет» или «Такого издания нет» );

Аналогичное содержание имеют описания таблиц Составители, Редакторы, Художники и Переиздания. Остальные же таблицы проектируемой базы данных описываются так:

СОЗДАТЬ ТАБЛИЦУ Переводчики *( Связывает Создатели, Издания и Языки) ПЕРВИЧНЫЙ КЛЮЧ ( Код_создателя, Код_издания ) ВНЕШНИЙ КЛЮЧ ( Код_создателя ИЗ Создатели NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Создатели ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Создатели.Код_создателя КАСКАДИРУЕТСЯ) ВНЕШНИЙ КЛЮЧ ( Код_издания ИЗ Издания NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Издания ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Издания.Код_издания КАСКАДИРУЕТСЯ) ВНЕШНИЙ КЛЮЧ ( Код_языка ИЗ Языки NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Языки ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Языки.Код_языка КАСКАДИРУЕТСЯ) ПОЛЯ ( Код_создателя Целое, Код_издания Целое ) ОГРАНИЧЕНИЯ ( Значения полей Код_создателя, Код_издания и Код_языка должны принадлежать набору значений соответствующих полей таблиц Создатели, Издание и Языки; при нарушении вывод сообщения «Такого автора нет» или «Такого издания нет» или «Такого языка нет»);СОЗДАТЬ ТАБЛИЦУ Размещение *( Связывает Места и Переплеты ) ПЕРВИЧНЫЙ КЛЮЧ ( Код_места, Номер_переплета ) ВНЕШНИЙ КЛЮЧ ( Код_места ИЗ Места NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Места ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Места.Код_места КАСКАДИРУЕТСЯ) ВНЕШНИЙ КЛЮЧ ( Номер_переплета ИЗ Переплеты NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Переплеты КАСКАДИРУЕТСЯ ОБНОВЛЕНИЕ Переплеты.Ном_переплета КАСКАДИРУЕТСЯ) ПОЛЯ ( Код_места Целое, Номер_переплета Целое, Дата_размещения Дата, Дата_изъятия Дата ) ОГРАНИЧЕНИЯ ( Значения полей Код_места и Номер_переплета должны принадлежать набору значений соответствующих полей таблиц Переплеты и Места; при нарушении вывод сообщения «Такого переплета нет» или «Такого места нет» );СОЗДАТЬ ТАБЛИЦУ Выдача *( Связывает Читатели и Переплеты ) ПЕРВИЧНЫЙ КЛЮЧ ( Ном_билета, Ном_переплета ) ВНЕШНИЙ КЛЮЧ ( Ном_билета ИЗ Читатели NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Читатели КАСКАДИРУЕТСЯ ОБНОВЛЕНИЕ Читатели.Ном_билета КАСКАДИРУЕТСЯ) ВНЕШНИЙ КЛЮЧ ( Ном_переплета ИЗ Переплеты NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Переплеты КАСКАДИРУЕТСЯ ОБНОВЛЕНИЕ Переплеты.Ном_переплета КАСКАДИРУЕТСЯ) ПОЛЯ ( Ном_билета Целое, Ном_переплета Целое, Дата_выдачи Дата, Срок Целое, Дата_возврата Дата ) ОГРАНИЧЕНИЯ ( Значения полей Ном_билета и Ном_переплета должны принадлежать набору значений соответствующих полей таблиц Читатели и Переплеты; при нарушении вывод сообщения «Такого читателя нет» или «Такого переплета нет» );

Теперь следует проверить, не нарушены ли в данном прокете какие-либо принципы нормализации (п. 4.6), т.е. что любое неключевое поле каждой таблицы:

  • функционально зависит от полного первичного ключа, а не от его части (если ключ составной);
  • не имеет функциональной зависимости от другого неключевого поля.
  • Сущности Авторы, Составители, Редакторы, Художники и Переиздания, не имеющие неключевых полей, безусловно нормализованы. Нормализованы и сущности Создатели, Характеры, Заглавия, Вид_издания и Аннотации, состоящие из несоставного ключа и единственного неключевого поля.

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

Наконец, анализ сущностей Издания, Переплеты, Места, Читатели и Языки, показал, что единственной «подозрительной» сущностью является стержень Языки, имеющий два функционально связанных неключевых поля: Язык и Сокращение.

Поле Язык стало неключевым из-за ввода цифрового первичного ключа Код_языка, заменяющего текстовый возможный ключ Язык. Это позволило уменьшить объем хранимых данных в таблице Переводчики, затраты труда на ввод множества текстовых значений и возможной противоречивости, которая часто возникает из-за ввода в разные поля ошибочных дубликатов (например, «Английский», «Англиский», «Анлийский», «Англйский» и т.п.). Если мы вспомним рекомендации п. 4.5 о замене на время нормализации цифровыз заменителей первичных ключей (Код_языка) на исходный ключ (Язык) или воспользуемся формулировкой НФБК, то окажется, что таблица Языки — нормализована.

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

ЛИТЕРАТУРА

ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ

Ведение (сопровождение, поддержка) данных — термин объединяющий действия по добавлению, удалению или изменению хранимых данных.

Предыдущая1234567

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *