17. Логическое проектирование

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

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

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

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

18. Физическое проектирование

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

19. Модели хранения данных

Иерархическая и сетевая модели хранения данных стали применяться в системах управления базами данных в начале 70-х годов. В начале 80-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.

Иерархическая модель хранения данных

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

Между главным и подчиненными типами объекта устанавливается взаимосвязь "один ко многим". Иными словами, для данного главного типа объекта существует несколько подчиненных типов объекта. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов. Таким образом, взаимосвязи между объектами напоминают взаимосвязи в генеалогическом древе за единственным исключением: для каждого порожденного (подчиненного) типа объекта может быть только один исходный (главный) тип объекта.

Сетевая модель хранения данных

В сетевой модели хранения данных понятия главного и подчиненных объектов несколько расширены. Любой объект может быть и главным, и подчиненным (в сетевой модели главный объект обозначается термином "владелец набора", а подчиненный - термином "член набора"). Один и тот же объект может одновременно выступать и в роли владельца, и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей.

Реляционная модель хранения данных

В реляционной модели хранения данных, как показано на рисунке,

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