Слайд 1ДАТАЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД
1. Подход к даталогическому про- ектированию
и определение сос-тава БД.
2. Метод проектирования реляцион-ной БД на основе
ИЛМ.
3. Пример проектирования РБД на основе ИЛМ и ДЛМ.
Слайд 2ВВЕДЕНИЕ
Цель даталогического проектиро-вания (ДЛМ) заключается в создании модели, которая отображает
логи-ческие связи между элементами данных безотносительно к их смысловому со-держанию
и среде хранения. Эта модель строится в терминах информационных единиц, предусмотренных в конкретной СУБД. Последовательность разработки ДЛМ показана на рис. 1, а расшифровка обозначений приводится на слайде 4.
Слайд 4Расшифровка обозначений на рисунке 1
Слайд 6На выбор проектных решений самое непо-средственное влияние оказывает специфи-ка предметной
области, отражённая в ИЛМ. Результатом даталогического проек-тирования является описание логической
структуры БД на языке описания данных. В спроектированной логической структуре БД должны быть определены все инфор-мационные единицы и связи между ними, заданы имена информационных единиц, их тип и количественные характеристики.
Слайд 7
1. Подход к даталогическому про- ектированию и определение
состава БД
Для любой предметной области суще-ствует множество проектных решений её
отображения в ДЛМ. Методика проекти-рования должна обеспечивать выбор наиболее подходящего проектного реше-ния. Минимальная логическая единица данных для всех СУБД семантически одинакова.
Слайд 8Связи между объектами предметной об-ласти, отражённые в ИЛМ, могут отобра-жаться
в ДЛМ либо посредством совмест-ного расположения соответствующих им информационных элементов,
либо путём объявления связи между ними. Не все виды связей, существующих в предметной области, могут быть непосредственно ото-бражены в конкретной ДЛМ. Так, многие СУБД не поддерживают непосредственно степень связи М:М между объектами.
Слайд 9В этом случае в ДЛМ вводятся дополни-тельные элементы, отображающие эту
связь. Связи могут быть представлены не только посредством структуры БД,
но и программным путём. Принимаемое про-ектное решение зависит не только от специфики отображаемой предметной области, но и от характера обработки ин-формации, хранимой в БД. Так, инфор-мацию, используемую часто, и инфор-мацию, частота обращения к которой мала, следует хранить в разных файлах.
Слайд 10При переходе от ИЛМ к ДЛМ следует иметь в виду,
что ИЛМ включает в себя всю информацию, необходимую и доста-точную
для проектирования БД. Но это не означает, что все свойства, зафиксирован-ные в ИЛМ, должны в явном виде отра-жаться в ДЛМ. Прежде, чем строить ДЛМ, необходимо решить, какая информация будет храниться в БД. Например, ИЛМ мо-жет содержать вычисляемые показатели, но вовсе не обязательно хранить их в БД.
Слайд 11Один из подходов к определению состава показателей, хранимых в БД,
основан на принципе синтезирования: в БД долж-ны храниться только исходные
показатели, а все производные показатели должны вы-числяться в момент выполнения запроса. Этот принцип имеет следующие достоин-ства: 1) простота и однозначность в приня-тии решения о том, «что хранить» в БД; 2) отсутствие явного дублирования инфор-мации; 3) потенциальная возможность по-лучить любой расчётный показатель.
Слайд 12Несмотря на эти достоинства, в каждом конкретном случае нужно оценивать
целе-сообразность хранения вычисляемых пока-зателей в БД с учётом частоты использо-вания
этих показателей.
При отображении объекта в БД иденти-фикатор объекта будет атрибутом, который в большинстве случаев используется для однозначной идентификации объекта. Од-нако может появиться необходимость вве-дения искусственных идентификаторов или кодов. Это нужно, когда:
Слайд 13 в предметной области наблюдается омо-нимия, например, среди студентов могут
быть полные тёзки. В этом случае для обеспечения однозначной идентификации
объектов необ-ходимо использовать коды;
если объект участвует во многих связях, то для идентификации связи удобнее исполь-зовать короткий код объекта, нежели длинный идентификатор объекта;
если естественный идентификатор может со временем изменяться, то при отсутствии кода это может вызвать проблемы с поиском нужных сведений.
Слайд 14
2. Метод проектирования
реляционной БД на основе ИЛМ
Рассмотрим метод
проектирования реляци-онной БД, основанной на анализе ИЛМ и переходе от
неё к отношениям ДЛМ. Этот метод является достаточно простым и на-глядным и в то же время даёт хорошие ре-зультаты. Для перехода от ИЛМ к реля-ционной ДЛМ используются следующие правила, в которых идентификаторы объек-тов обозначены через ИО1, ИО2, ИО3, а их свойства – через С1, С2 и т.д.
Слайд 152.1. Для каждого простого объекта и его еди-ничных свойств строится
отношение, ат-рибутами которого являются идентифи-катор объекта и реквизиты, соответству-ющие каждому
из единичных свойств:
ИО1
С1
С2
С3
ИЛМ
R1(ИО1, С1, С2, С3)
ДЛМ
Слайд 162.2. Если у объекта имеются множественные свойства, то каждому из
них ставится в соот-ветствие отдельное отношение. Ключом этого отношения будет
идентификатор соответству-ющего объекта и реквизит, отражающий множественное свойство:
С4
С1
R1(ИО1, С1, С2)
R2(ИО1, С3)
R3(ИО1, С4)
Слайд 17
2.3. Если между объектом и его свойством имеется условная связь
(условное свойство), то при отображении в ДЛМ возможны следую-щие варианты:
а)
если многие из объектов обладают услов-ным свойством, то его можно хранить в БД так же, как и обычное свойство;
б) если только незначительное число объек-тов обладает условным свойством, то можно выделить отношение, которое будет включать идентификатор объекта и атрибут, соответст-вующий условному свойству.
Слайд 18
Это отношение будет содержать столько строк, сколько объектов имеют условное
свойство:
R1(ИО1, С1, С2)
или
R1(ИО1, С1)
R1(ИО1, С2)
Слайд 192.4. Если объект имеет составное свойство С, то оно представляется
в отношении набором атрибутов С1, С2, соответствующих элемен-там составного свойства:
С
R1(ИО1, С1, С2, С3)
Слайд 202.5. Если между объектами имеется степень связи 1:1, то ДЛМ
определяется классом при-надлежности объектов. Если класс принад-лежности обоих объектов является
обязатель-ным, то ДЛМ задаётся одним отношением, в котором атрибутами будут идентификаторы объектов и свойства обоих объектов:
ИО1
ИО2
С1
С2
R1(ИО1, С1,…, ИО2, С2,…)
Слайд 21Такая модель потребует меньше всего памя-ти. Однако если в запросах
часто требуется информация отдельно по каждому из объ-ектов, то для
ускорения поиска информа-ции целесообразно каждый объект пред-ставить отдельным отношением, а связь объектов представить в ДЛМ, указав иден-тификатор одного объекта в качестве атри-бута в отношении, соответствующем друго-му объекту, например:
R1(ИО1, С1,…, ИО2)
R1(ИО2, С2)
Слайд 22Если класс принадлежности одного из объ-ектов необязательный, то ДЛМ задаётся
двумя отношениями, причём идентифика-тор объекта, для которого класс принад-лежности является
необязательным, добав-ляется в качестве атрибута в отношение, соответствующее объекту с обязательным классом принадлежности:
ИО1
R1(ИО1, С1,…)
R2(
ИО2, С2,…, ИО1)
Слайд 23Если класс принадлежности обоих объек-тов является необязательным, то ДЛМ за-даётся
тремя отношениями - по одному для каждого объекта и одно
для отображения связи между объектами:
ИО2
С1
С2
R1(ИО1, С1,…)
R2(
ИО2, С2,…)
R3(ИО1, ИО2)
Слайд 242.6. Если между объектами имеется степень связи 1:М и класс
принадлежности много-связного объекта является обязательным, то независимо от класса принадлежности
односвязного объекта ДЛМ задаётся двумя отношениями – по одному для каждого объекта. Отношение, соответствующее мно-госвязному объекту можно дополнить ат-рибутом, являющимся идентификатором (ключом) односвязного объекта:
Слайд 25R1(ИО1, С1)
R2(
ИО2, С2, ИО1)
Рисунок к п. 2.6, когда степень связи
имеет вид 1:М, а класс принадлежности многосвязного объекта является обязательным
Слайд 26Если класс принадлежности многосвязного объекта является необязательным, то ДЛМ задаётся
тремя отношениями – по одному для каждого объекта и одно
для отображе-ния связи между объектами. Связь объек-тов задаётся атрибутами, являющимися идентификаторами (ключами) объектов:
R1(ИО1, С1)
R2(ИО2, С2)
R3(ИО1, ИО2)
Слайд 272.7. Если между объектами предметной об-ласти имеется степень связи М:М,
то ДЛМ задаётся тремя отношениями независимо от класса принадлежности объектов:
R1(ИО1, С1)
R2(ИО2, С2)
R3(ИО1, ИО2)
Слайд 282.8. Каждому агрегированному объекту, имею-щемуся в предметной области, в ДЛМ
соот-ветствует отдельное отношение. Атрибутами этого отношения будут идентификаторы всех объектов,
входящих в агрегированный объект, а также свойства этого объекта:
R1(ИО1, ИО2, ИО3, С1, С2)
Слайд 292.9. При отображении обобщённых объектов возможны разные решения.
Во-первых, всему
обобщённому объекту может быть поставлено в соответствие одно отношение.
Во-вторых,
каждой категории объектов нижнего уровня ставится в соответствие отдельное отношение.
В первом случае атрибутами отношения будут все единичные свойства, присущие объ-ектам хотя бы одной категории плюс иденти-фикатор объекта.
Слайд 30Во втором случае каждое отношение включает в себя идентификатор объекта,
те свойства, ко-торые присущи объектам данной категории, а также свойства,
которыми обладают родовые объекты, стоящие выше его по иерархии:
Кроме рассмотренных двух случаев возможны и комбини-рованные варианты.
R1(ИО1, С1, С2, С3, С4, С5, С6, С7)
или
R1(ИО1, С1, С2, С4, С5)
R1(ИО1, С1, С2, С6, С7)
Слайд 312.10. Составной объект, для которого характер-но наличие связи «целое-часть», может
быть отображён в ДЛМ по-разному. Если рассматри-ваемая связь реализована на
однородном мно-жестве объектов, то для отображения связи в этом случае можно использовать два отноше-ния. Первое из них будет содержать информа-цию о самих объектах, а второе – информацию о связи между ними, а также дополнительную информацию, характеризующую эту связь. В большинстве случаев для построения ДЛМ можно использовать рекомендации правила 6.
Слайд 322.11. В некоторых случаях одних объектов (сущностей) и связей может
оказаться недо-статочно для всестороннего моделирования предметной области. Один из таких
случаев возникает тогда, когда экземпляры некоторой сущности должны играть разные роли в дея-тельности организации. Например, предполо-жим, что для кафедры института необходимо хранить информацию о процессе подготовки научных кадров. Различают две категории объектов в этом процессе: преподаватели и аспиранты.
Слайд 33И те и другие являются научными кадрами, но играют разные
роли в процессе подготовки научных кадров: преподаватели передают свои знания,
а аспиранты приобретают эти знания.
С учётом указанных ролей диаграмма ER-типа будет иметь следующий вид:
Слайд 34При разработке ДЛМ можно следовать такому правилу. Исходная сущность представляется
одним отношением, причём ключ сущности служит первичным ключом. Ролевые объекты
м связи, их соединяющие, представляются в ДЛМ таким числом отношений, которое определяет-ся ранее описанными правилами, причём каж-дая роль трактуется как обычная сущность. Согласно этому правилу для нашего примера ДЛМ задаётся тремя отношениями:
R1(НК,…) R2(НП,…) R3(НА,…, НП)
Слайд 362.12. До сих пор в ИЛМ присутствовали связи только между
парами объектов. Но могут воз-никнуть и такие ситуации, в которых
между объектами существуют связи более высокого порядка. Например, рассмотрим ситуацию приёма экзаменов преподавателями в группах, представив её в виде диаграмм ER-экземп-ляров и ER-типа (на рисунке 3 следующего слайда введены следующие обозначения: НП – номер преподавателя, ИЭ – идентификатор экзамена, ШГ – шифр группы, M:N, M:L – связи более высокого порядка).
Слайд 37
П1
П2
ПРЕПОДАВАТЕЛЬ
ГРУППА
ЭКЗАМЕН
Э1
Э3
Э2
(Мат. анализ)
(Базы данных)
(Информатика)
МТМ-б-о-121
ПМИ-б-о-111
Рисунок 2 - Диаграмма ER-экземпляров
ЭКЗАМЕН
ПРЕПОДАВАТЕЛЬ
ГРУППА
ИЭ…
НП…
ШГ…
м
N
L
GHBYBVFTN
ПРИНИМАЕТ
Рисунок 3 - Диаграмма ER-типа
Слайд 38В случае трёхсторонних связей в ИЛМ датало-гическая модель состоит из
четырёх отноше-ний: по одному для каждой сущности, причём ключ каждой
сущности должен служить пер-вичным ключом для соответствующего от-ношения, и одно отношение для связи сущнос-тей. Отношение, порождённое связью, будет иметь среди своих атрибутов ключи сущностей от каждой сущности. Для рассматриваемого примера ДЛМ состоит из таких отношений:
R1(НП,…) R2(ИЭ,…)
R3(ШГ,…) R4(НП, ИЭ, ШГ,…)
Слайд 39При наличии n-сторонней связи требуется n+1 отношение: n отношений для
сущнос-тей и одно отношение для связи. Полу-ченная таким образом ДЛМ
содержит от-ношение для связи, которое напоминает результат применение правила 8 для агре-гированного объекта. Это не случайно, по-скольку ИЛМ отображает один процесс, в который вовлечено несколько объектов, то есть предметную область можно тракто-вать как агрегированный объект, именуе-мый ПРИЁМОМ ЭКЗАМЕНОВ.
Слайд 403. ПРИМЕР ПРОЕКТИРОВАНИЯ РБД НА ОСНОВЕ ИЛМ и ДЛМ
Возьмём в
качестве предметной области жителей некоторого города и спроекти-руем простейшую реляционную
базу дан-ных, в которой будут храниться сведения, представляющие интерес для налоговой инспекции. Проектирование начинается с разработки ИЛМ, которая включает в себя компоненты, изображённые на ри-сунке 1 предыдущей темы.
Слайд 413.1. Описание объектов и связей между ними
Объектами, представляющими интерес, будут
ЖИТЕЛЬ, КВАРТИРА, ТЕЛЕФОН, ДОХОД. Опишем каждый из них и связи
между ними.
ЖИТЕЛЬ
Nom
FIO
Rdate
Pol
SumD
s
s
s
D
D
Порядковый номер жителя
Фамилия, имя, отчество
Дата рождения
Пол: М – мужской, Ж - женский
Общий доход
Слайд 42Категория квартиры
П – приватизирована
Н - не приватизирована
К - коммунальная
Слайд 44Связи между объектами отражаются на диаграмме ER-типа:
ЖИТЕЛЬ
КВАРТИРА
ТЕЛЕФОН
ДОХОД
Nom…
Adr…
Ntel…
Id…
ЖИВЁТ
ИМЕЕТ_Т
ИМЕЕТ_Д
Слайд 453.2. Лингвистические отношения
В лингвистических отношениях должно быть дано толкование используемых
в ИЛМ терми-нов и понятий, например:
Nom – уникальный номер жителя
данного города, в качестве которого используется целое число;
Adr – адрес жителя; задаётся указанием ули-цы, номера дома (корпуса) и квартиры;
Source – обозначение источника дохода: Пенсия1 – пенсия по старости; Пособие1 – пособие на ребёнка; Стипендия1 – повышенная стипендия; Работа1 – работа в банке и т.д.
Money – размер дохода в рублях.
Слайд 463.3. Алгоритмические связи показателей
Из всех показателей, отражённых в ИЛМ, ал-горитмически
связанным является общий до-ход (SumD). Его вычисление описывается сле-дующим графом
взаимосвязи показателей:
Money
Money
Money
ДОХОД
…
…
Слайд 473.4. Описание информационных потребностей пользователей
Здесь должны быть определены все запросы,
которые будут поступать от пользователей БД, например:
вывести список всех жителей
с указанием общего дохода;
вывести список жителей, у которых общий доход не меньше облагаемого минимума;
подсчитать налоги отдельных жителей и общую сумму налогов и т.д.
Этот компонент служит основой для раз-работки БД.
Слайд 483.5. Ограничения целостности
Ограничения целостности используются при разработке БД, чтобы контролировать
правильность данных, вводимых в БД, и кор-ректность вычислений. Например, размер
до-хода не должен быть отрицательным, источник дохода должен выбираться из известного списка и т.п. Таким образом, в данном ком-поненте ДЛМ формулируются условия, ко-торым должны удовлетворять отдельные пока-затели и группы показателей, чтобы инфор-мация, хранимая в БД, имела смысл.
Слайд 493.6. Описание структуры БД на основе языка ДЛМ
Будем хранить в
этой БД все показатели, в том числе и вычисляемый показатель
SumD, поскольку его значение требуется при выполнении многих запросов. Введём теперь отношения, включаемые в БД. Для этой цели применим соот-ветствующие правила из п.2 к каждой паре связанных объектов, изображённых на диаграмме ER-типа (рисунок п. 3.1).
Слайд 50Согласно правилу 6 связанные объекты ЖИТЕЛЬ-КВАРТИРА представляются двумя отношениями:
PERSON’(Nom,…, Adr)
FLAT’(Adr, …)
Согласно правилу
7 связанные объекты ЖИТЕЛЬ-ДОХОД представляются тремя отношениями:
PERSON’’(Nom,…)
PROFIT’’(Id, …)
HAVE_D’’(Nom, Id)
Согласно правилу 5 связанные объекты КВАРТИ-РА-ТЕЛЕФОН представляются двумя отношения-ми:
FLAT’’’(Adr, …)
TFONE’’’(Ntel, …, Adr)
Слайд 51Анализ этих семи отношений позволяет устано-вить, что для отображения ИЛМ
предметной области в ДЛМ достаточно пяти отношений:
PERSON(Nom, Fio, Rdate, Pol, SumD, Adr)
FLAT(Adr, Skv, Nrooms, Kcategory)
HAVE_D(Nom, Id)
TFONE(Ntel, Tcategory, Adr)
PROFIT(Id, Sourse, Money)
Даталогическое проектирование завершается описанием логической структуры БД на языке конкретной СУБД. Это описание называется схемой БД и помимо всего прочего содержит такие характеристики атрибутов отношений как тип и длина (размер) атрибута.
Слайд 52Ввод информации в БД и получение нуж-ной информации из БД
осуществляются либо непосредственно средствами СУБД, либо с помощью специально разработан-ной
прикладной системы, использующей команды СУБД.
Можно легко проверить, что спроектиро-ванная РБД не создаёт проблем вставки, обновления и удаления информации при работе с ней, то есть аномалий вставки, обновления и удаления не возникает.
Слайд 53Пусть, например, появился новый житель, у ко-торого отсутствуют источники дохода.
Тогда ин-формация о жителе будет занесена только в от-ношение PERSON,
причём даже атрибут SumD будет иметь определённое (нулевое) значение, соответствующее действительности и аномалии вставки не возникает.
Аномалии обновления не возникает при изме-нении адреса у конкретного жителя, поскольку в этом случае будет обновляться атрибут Adr в кор-теже отношения PERSON и, возможно, появится новый кортеж с описанием адреса и характерис-тик квартиры в отношении FLAT, если в БД не было сведений об этой квартире.
Слайд 54Не проявляется аномалия обновления и при изменении номера телефона, установленного
в квартире. Если об этом сообщит любой из жите-лей такой
квартиры, то изменения отразятся толь-ко в одном кортеже отношения TFONE (обновится только номер телефона).
Аномалия удаления. Пусть налоговый инспектор узнаёт, что житель Иванов П.Р. лишился своего источника дохода, условно названного РАБОТА2, и удаляет этот кортеж из отношения HAVE_D. После этого сведения о существовании Иванова остаются в отношении PERSON без изменений и аномалии удаления не возникает.
Слайд 55ЗАКЛЮЧЕНИЕ
Попытаемся свести в некоторый перечень ос-новные действия, которые обычно приходится
выполнять в процессе проектирования реля-ционной БД с использованием метода «сущность-связь»
при нормализации проектного решения до третьей нормальной формы.
детально изучить предметную область в целях составления её словесного описания и конкре-тизации необходимых бизнес-правил. Сформу—лировать функциональные требования к БД, выявив основные запросы и транзакции;
Слайд 56 выявить объекты (сущности), которые необ-ходимо включить в модель, и
определить первичные ключи каждого из выявленных объектов;
выявить и описать
смысл, тип и возможные значения всех представляющих интерес атри-бутов для каждого объекта. Определить доме-ны (области значений) для каждого атрибута;
определить типы связей между выявленными объектами;
построить графическое описание логической модели предметной области в виде ER-диа-грамм с указанием степеней связи и классов принадлежностей;
Слайд 57 построить графическое описание функцио-нальных зависимостей между атрибутами и выявить
минимальное покрытие;
для построенной диаграммы ER-типа получить предварительные отношения и
разместить в них выявленные атрибуты объектов;
выполнить нормализацию модели, используя минимальное покрытие;
принять обоснованные решения по введению в модель контролируемой избыточности и спо-собов её контроля;
получить окончательное проектное решение в виде наборов отношений с присвоенными им
Слайд 58смысловыми именами, указанными ключами и перечнем атрибутов для каждого отношения.
Проверить, все ли атрибуты нашли своё место;
убедиться в возможности реализации
необхо-димой функциональности БД на полученном проектном решении.
Разумеется, на практике эти пункты выполня-ются не в жёсткой последовательности. Опытные проектировщики обычно подразумевают нали-чие диаграммы ER-типа или концептуальной мо-дели и зачастую ограничиваются изображением логической модели БД в некоторой автомати-зированной среде проектирования БД.
Слайд 59РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
Дейт, К., Дж. Ведение в системы баз данных, 7-е
издание: пер. с англ. – М.: Издательский дом «Вильямс», 2001.
– 1072 с.
Илюшечкин, В.М. Основы использования и проектирования баз данных: учеб. посо-бие/В.М. Илюшечкин. – М.: Высшее обра-зование, 2009. -213 с. – (Основы наук).
Мирошниченко, Г.А. Реляционные базы дан-ных: практические приёмы оптимальных ре-шений. – СПб.: БХВ-Петербург, 2005. – 400 с.