Студопедия

КАТЕГОРИИ:


Архитектура-(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)

Бизнес-модель этапа проектирования - создание физической модели реляционной базы данных




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

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

  • Создание базовых таблиц. Они представляют основные блоки хранения данных и выводятся из сущностей логической модели данных. При создании каждой таблицы проектировщик должен рассмотреть и учесть ряд факторов:
    • определить список колонок в таблице. Колонки выводятся из атрибутов сущности логической модели данных;
    • определить типы данных для каждой колонки. Типы данных колонок либо заданы спецификацией домена атрибута логической модели, либо определяются проектировщиком самостоятельно;
    • определить имя таблицы. Оно может быть выведено из имени сущности логической модели базы данных или задано проектировщиком самостоятельно. Желательно в этот момент определить собственника таблицы - пользователя, который будет иметь все права доступа на таблицу, а также потенциальных пользователей таблицы;
    • определить ряд параметров, связанных с характером хранения таблицы в физической базе данных;
    • определить ограничения на значения колонок, исходя из ряда бизнес-правил.
  • Создание связывающих таблиц, необходимых для разрешения отношения "многие-ко-многим", если они имеют место в логической модели базы данных. В рамках ER-диаграмм это отношение может быть уже разрешено. Тогда речь пойдет только о его реализации в командах SQL.
  • Принять решение о способе поддержки ссылочной целостности в базе данных. Если будет решено поддерживать ссылочную целостность на уровне команд SQL, то специфицировать ограничения ссылочной целостности. Эта задача решается в четыре этапа:
    • идентифицировать первичные ключи каждой таблицы;
    • построить индексы первичного ключа;
    • определить внешние ключи в дочерних таблицах, если необходимо;
    • построить команды SQL, которые идентифицируют внешние ключи в дочерних таблицах и правила поддержки ссылочной целостности;
    • Если необходимо, построить представления внешней схемы базы данных.

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

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

Создание объектов для хранения данных Создание таблиц Идентифицировать таблицу Определение типов данных колонок Определение первичного ключа Добавление ограничений Создание таблиц для взаимосвязи "многие-ко-многим" Создание индексов Создание представлений Создание других объектов базы данных Проверка корректности созданной физической модели

На рис. 3.7 ниже представлена модель бизнес-процессов первой итерации физической модели базы данных, а на рис. 3.8 - декомпозиция работы по созданию базовой таблицы.


Рис. 3.7. Декомпозиция этапа проектирования - создание первой итерации физической модели базы данных: внутренняя схема


Рис. 3.8. Декомпозиция работы по созданию базовой таблицы

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




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


Дата добавления: 2014-01-07; Просмотров: 2243; Нарушение авторских прав?; Мы поможем в написании вашей работы!


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



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




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