Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Этап построения внутренней модели




Проектирование внутренней модели базы данных проводится с учетом выбранной конкретной СУБД (рекомендуется MS SQL Server). Исходными данными для разработки внутренней модели являются:

· концептуальная модель, представляющая собой отображение предметной области;

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

 

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

· получение спецификаций внутренней схемы – перевод структурных спецификаций схемы базы данных с полноатрибутного IDEF1X-представления в описание на языке конкретной СУБД;

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

 

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

· набор базовых структурных элементов для представления данных и схем данных (атрибуты, домены, схемы отношений);

· правила порождения ограничений на допустимые состояния данных (ограничения целостности).

 

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

 

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

- имя домена

- тип данных СУБД для данного домена

- обязательность домена (NULL или NOT NULL)

- ограничения, наложенные на значения домена

 

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

 

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

 

Реализация ссылочных ограничений целостности

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

Дочернее отношение – Name2/E2

· Операция INSERT выполняется без каких-либо ограничений при условии, что в новом (вставляемом) кортеже значение атрибутов первичного ключа (Id2) уникально, и значение атрибутов внешнего ключа (Id1) имеется в каком-либо кортеже родительского отношения Name1. Например, может быть вставлен кортеж <4, 2, …>.

· Операция DELETE выполняется без каких-либо ограничений. Например, может быть удален кортеж <2, 2, …>.

· Операция UPDATE, затрагивающая значения атрибутов первичного и/или внешнего ключей, выполняется с такими же ограничениями, что и операция INSERT. Например, в кортеже <2, 2, …> может быть модифицировано значение первичного ключа и получен кортеж <4, 2, …> (при условии, что в отношении Name2 нет кортежа с таким значением первичного ключа) или может быть модифицировано значение внешнего ключа и получен кортеж <2, 1, …>.

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

· Родительское отношение – Name1/E1

· Операция INSERT выполняется без каких-либо ограничений при условии, что соблюдается уникальность значений ключевых атрибутов (Id1). Так, например, может быть вставлен кортеж <4, …, …>;

· Операция DELETE требует уточнения: как должно выполняться удаление некоторого кортежа родительского отношения при условии, что в дочернем отношении существует кортеж, ссылающийся на удаляемый.

· В СУБД MS SQL Server поддерживаются три вида реакции на удаление кортежа родительского отношения:

o CASCADE – при удалении кортежа родительского отношения удаляются все ссылающиеся на него кортежи дочернего отношения. Так, если в рассматриваемом примере из родительского отношения Name1 удаляется кортеж <1, …, …>, то из дочернего отношения Name2 автоматически будут удалены кортежи <1, 1, …> и <3, 1, …>.

o NO ACTION – при удалении кортежа родительского отношения операция удаления не выполняется, если в дочернем отношении есть хотя бы один кортеж, ссылающийся на удаляемый. Так, при попытке удалить кортеж <2, …, …> родительского отношения Name1 операция удаления не будет выполнена.

o SET NULL – при удалении кортежа родительского отношения в поле внешнего ключа всех ссылающихся на него кортежей дочернего отношения устанавливается значение NULL (очевидно, что при создании дочерней таблицы поле внешнего ключа должно быть определено как NULL – допускает задание NULL значений).

· Операция UPDATE, затрагивающая значение атрибутов первичного ключа, требует таких же уточнений, что и операция DELETE. Эта операция также допускает три вида реакции: CASCADE, NO ACTION и SET NULL, имеющие тот же смысл.

 

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

 

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

 

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

 

Имя домена Тип данных Признак обязательности Ограничения на домен

Заголовок таблицы описания доменов

Имя связи Родительское отношение Дочернее отношение Правило удаления Правило обновления

Заголовок таблицы описания ссылочной целостности

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

В графе "Имя атрибута" указывается имя атрибута, использованное в инфологической модели.

В графе "Имя колонки" указывается имя атрибута, построенное в соответствии с правилами построения имен атрибутов в данной СУБД.

В графе "Имя домена" указывается имя домена, на котором построен данный атрибут.

В графе "Ключи" указываются дополнительные сведения об атрибуте, если он относится к ключевым (первичный ключ, альтернативный ключ, внешний ключ).

В графе "Правило удаления" (только для атрибутов внешних ключей) указывается имя родительской таблицы и выбранная реакция на удаление связанной строки родительской таблицы (no action, cascade).

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

Поставка (Номер поставщика, Номер детали, Дата поставки, Количество)

 




Поделиться с друзьями:


Дата добавления: 2015-05-09; Просмотров: 335; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.025 сек.