Когда мы говорим о проектировании баз данных, надо иметь в виду, что оно является лишь частью проектирования всей информационной системы. Мы довольно подробно рассматриваем вопросы проектирования самой важной части любой информационной системы – информационного хранилища или базы данных. Действительно проектирование базы данных имеет несомненный приоритет по отношению к функциональной части системы. На это есть несколько причин, одна из которых заключается в том, что при проектировании функциональной части системы желательно уже определится с именами, используемыми для обозначения хранящихся в базе данных объектов. Кроме этого заметим, что после начала эксплуатации информационной системы не желательно, а часто и довольно сложно менять структуру базы данных, в отличие от ее программной части.
Многолетний опыт показывает, что можно выделить три уровня проектирования баз данных: концептуальный, логический и физический. Кратко остановимся на каждом из этих уровней.
■ Концептуальный уровень. Строится общая модель базы данных. За основу берется описание предметной области. В качестве языка описания может быть и естественный язык, и какой либо формализованный язык, например язык UML (Unified Modeling Language – универсальный язык моделирования). Описание предметной области называют еще внешним уровнем проектирования. На концептуальном уровне проектирования должна быть представлена схема, включающая единое описание всех элементов данных (имена элементов) и отношений между ними. В дальнейшем элементы будут называться нами сущностями. Схема представляет собой некоторый общий взгляд на предмет проектирования, позволяет единым взглядом охватить информацию, которые будут храниться в базе данных. При создании и анализе концептуальной модели следует особо обратить внимание на возможность осуществления на основе модели основных операций (транзакций), которые должна выполнять информационная система.
■ Логический уровень проектирования представляет собой детализацию элементов концептуальной схемы: описание характеристик элементов (атрибутов) и связей между элементами. Именно на этом уровне могут появиться новые сущности, и нам придется возвратиться к концептуальному уровню проектирования базы данных. Логический уровень проектирования уже весьма близок к схеме реляционной базы данных. Именно здесь мы должны определиться с первичными ключами, обозначить типы связи их имена и характеристики, определить ограничения, накладываемые на хранимые в базе данные.
■ На физическом уровне проектирования логическая модель данных преобразуется к реляционной базе данных конкретной СУБД. Происходит преобразование сущностей логической модели в конкретные таблицы, атрибуты сущностей в атрибуты (столбцы) таблицы, связи между сущностями в связи между таблицами, первичные ключи сущностей в первичные ключи таблиц. Кроме этого создаются индексы таблиц, а также реализуются ограничения целостности базы данных средствами конкретной СУБД. Заметим также, что возможно на данном этапе может потребоваться нормализация некоторых таблиц.
После завершения проектирование базы данных на физическом уровне реализуются другие задачи создания информационной системы: проектируется система безопасности информационной системы и создается программная составляющая на стороне сервера (триггеры, хранимые процедуры, функции, представления). Наконец после создания программной части на стороне сервера можно приступать к программированию клиента.
Модель «сущность - связь» (или ER-модель) представляет собой способ логического унифицированного представления данных некоторой предметной области. Хотя, как мы увидим далее, эта модель очень напоминает систему связанных друг с другом таблиц, в действительности это совершенно общее представление. Эта модель может быть преобразована к любой из существующих конкретных моделей данных: иерархической, сетевой, реляционной, объектной. Существенно, что ER-модель позволяет представлять только данные, но не действия, которые с ними могут производиться, поэтому она используется лишь для проектирования структуры хранимых данных. Поскольку многие понятия, которые мы будем разбирать в связи с моделью «сущность - связь» были нами рассмотрены в основах реляционных баз данных (параграфы 1.1,1.2,1.3), будем опираться на эти знания.
Достоинствами данной модели являются
· Простота
· Наглядность.
· Однозначность.
· Использование естественного языка.
Определение
Сущность это собирательное понятие, некоторая абстракция реально существующего объекта, процесса, явления или некоторого представления об объекте, информацию о котором требуется хранить в базе данных.
Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д. Предполагается, что гарантировано отличие экземпляров одного типа сущности друг от друга. Данное требование вполне аналогично требованию отсутствия в таблице тождественных строк. В дальнейшем, однако, там, где это не может вызвать неоднозначного прочтения, мы не будем различать типы и экземпляры, а будем просто использовать термин «сущность». Принято выражать (именовать) сущность существительным или существительным с характеризующим его прилагательным (СТУДЕНТ, ДЕКАНАТ, ВЫПУСКАЮЩАЯ КАФЕДРА и др.).
Выделяют три вида сущностей: стержневая, ассоциативная (ассоциация) и характеристическая (характеристика). Кроме этого во множестве ассоциативных сущностей также определяют подмножество обозначений. Дадим теперь определение видам сущностей.
Стержневая сущность.
Стержневая (сильная) сущность – независящая от других сущность. Стержневая сущность не может быть ассоциацией, характеристикой или обозначением (см. ниже).
Ассоциация.
Ассоциативная сущность (или ассоциация) выражает собой связь «многие ко многим» между двумя сущностями. Является вполне самостоятельной сущностью. Например, между сущностями МУЖЧИНА и ЖЕНЩИНА существует ассоциативная связь, выражаемая ассоциативной сущностью БРАК.
Характеристика.
Характеристическую сущность еще называют слабой сущностью. Она связана с более сильной сущностью связями «один ко многим» и «один к одному». Характеристическая сущность описывает или уточняет другую сущность. Она полностью зависит от нее и исчезает с исчезновением последней. Например, сущность Зарплата является характеристикой конкретных работников предприятия и не может в таком контексте существовать самостоятельно – при удалении экземпляра сущности Работника должны быть удалены и экземпляры сущности Зарплата, связанные с удаляемым работником.
Обозначение.
Обозначение это такая сущность, с которой другие сущности связаны по принципу «многие к одному» или «один к одному». Обозначение, в отличие характеристики является самостоятельной сущностью. Например, сущность Факультет обозначает принадлежность студента к данному подразделению института, но является вполне самостоятельной.
Любой фрагмент предметной области может быть представлен некоторым набором сущностей и связями между ними. Например, рассматривая предметную область ФАКУЛЬТЕТ можно выделить следующие основные сущности: СТУДЕНТ, КАФЕДРА, СПЕЦИАЛЬНОСТЬ, ДЕКАНАТ, ГРУППА, ПРЕПОДАВАТЕЛЬ, ЭКЗАМЕН. На первом этапе создания ER-модели данных следует выделить все сущности, которые предполагается описывать исходя из постановки задачи. Лишний раз подчеркнем, что сущностью может быть не только некоторый материальный объект, но и некоторый процесс, например ЭКЗАМЕН, ЛЕКЦИЯ. Сущностью может быть и некоторая количественная и качественные характеристики объекта: УЧЕНОЕ ЗВАНИЕ, СТАЖ и др. Все в действительности зависит от постановки задачи и от нашего анализа предметной области.
Рассмотрим другие важные понятия, используемые при построении ER-модели. Мы ввели уже понятие сущности. Остановимся на трех других Понятиях: атрибут сущности, ключ, связь.