Практическая работа №1
Тема: «Проектирование структуры базы данных».
Цель работы: научиться проектировать логическую и физическую модель базы данных.
Краткие теоретические сведения:
Проектирование базы данных
Обычно проектирование базы данных начинается с разработки схемы базы данных. Схема БД — это графическое изображение таблиц и связей между ними. Такой «чертеж» БД позволяет легко разобраться в архитектуре БД. Схема базы данных разрабатывается на основе результатов предпроектного обследования предприятия. На этапе предпроектного обследования определяются список документов и справочники, которые будут храниться в БД. Каждый документ анализируется:
определяются его структура,
типы данных для полей документов
связи документа и т. д.
Построение схемы базы данных производится в три этапа:
строится схема логическая модель данных,
затем на ее основе физическая модель данных,
последний этап генерация базы данных.
Генерация БД производится основе физической модели данных. После этого база данных готова к эксплуатации. Для проектирования моделей данных используются специальные программы, позволяющие визуально проектировать БД.
Логическая модель данных
В процессе создания логической модели данных принимаются принципиальные решения, касающиеся архитектуры БД. От них в первую очередь зависит эффективность программного продукта. Эти решения не зависят от особенностей конкретной реализации СУБД. В логической модели БД определяются:
имена таблиц;
имена атрибутов;
ключи;
связи между таблицами;
приблизительно определяются типы доменов.
Заметим, что у различных СУБД допустимые типы данных совпадают не полностью, поэтому на этом этапе реализации проекта они определяются приблизительно или вообще не определяются. Логическая модель представляет собой схему, которая состоит из графических образов таблиц (Entity) и связей (Relation) между ними. На рис. 1 приведено условное обозначение для таблицы PGRANT.
Рис. 1. Условное обозначение таблицы PGRANT в логической модели
Рис. 2. Графическое изображение различных типов связей
Обозначения для различных типов связей приведены на рис. 2. Черной точкой на связи помечается таблица-справочник.
Пример. Логическая модель данных проекта «ГРАНТ»
Построим логическую модель нашего фрагмента системы «ГРАНТ». В базе данных будет четыре таблицы — столько же, сколько и исходных документов, такое совпадение случается далеко не всегда. В таблице 7.1 приведен перечень таблиц, которые будут созданы в нашей базе данных, имена, под которыми они будут зарегистрированы, а также определены имена столбцов таблицы. Обратите внимание, что перечень столбцов таблиц базы данных не совпадает с соответствующим перечнем столбцов соответствующих документов. Так, в таблицах ANKETA, PLATEG отсутствуют столбцы с названием гранта, а в PAYSHEET отсутствуют фамилия, имя и отчество получателя денежного вознаграждения. Соответствие между грантом и его участниками, а также между грантом и произведенными платежами по нему устанавливается при помощи внешних ключей. В логической модели данных типы доменов, как мы уже знаем, можно не определять или назначить их приблизительно. Они будут уточнены на уровне физической модели данных, когда будет принято решение относительно СУБД, на которой будет реализована БД.
Таблица 1. Описание полей таблиц проекта «ГРАНТ»
Каждое имя поля начинается с префикса, который указывает на тип данных. Это соглашение полностью себя оправдывает на практике, и желательно его придерживаться.
Первичные ключи. Как было показано в таблицах БД «ГРАНТ», целесообразно определить автоинкрементальные первичные ключи. Для этого дополним каждую таблицу столбцом для автокрементального первичного ключа. Для того чтобы ключевое поле было легко узнаваемо, его имя будет начинаться с ГО_*. После звездочки запишем сокращенное название таблицы, для которой он создан.
Связи. Установим связи между таблицами:
PGRANT-ANKETA
PGRANT-PLATEG -ANKETA-PAYSHEET
PGRANT-ANKETA. При помощи этой связи устанавливается соответствие между грантом и его участниками. Таблица PGRANT будет предком, а таблица ANKETA — потомком. Для внешнего ключа, посредством которого будет установлена связь необходимо, определить новый столбец. Назовем его, так же как и поле первичного ключа в таблице PGRANT, — IDGP. Предусмотрим возможность хранить в таблице анкетные данные сотрудников, не участвующих в грантах. Это целесообразно по следующим причинам. Сотрудник может временно не участвовать в работах по грантам или этот список может быть использован для других целей. Например, завхоз Осипов Г. С. в настоящей момент не участвует в реализации гранта, поэтому тип связи установим необязательной.
PGRANT-PLATEG. Эта связь напоминает только что рассмотренную. Связь устанавливает соответствие межу грантом и платежами, которые были проведены по нему. Таблица PGRANT будет предком, а таблица PLATEG — потомком. Для внешнего ключа определим новый столбец, назовем его так же — IDGP. Так как каждый платеж должен относится к некоторому гранту, то тип связи будет обязательный. Просто так деньги не приходят.
ANKETA-PAYSHEET. Связь устанавливает соответствие между исполнителем и полученными им вознаграждениями. Таблица ANKETA будет предком, а таблица PAYSHEET — потомком. Для внешнего ключа определим столбец I D_ANK. Так как каждая выплата относится к некоторому исполнителю, то тип связи обязательный. Деньги платятся кому-то.
Логическая модель БД для нашего фрагмента информационной системы представлена на следующем рисунке.
Рис. 3. Логическая модель данных