ДАТАЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД

Содержание

Слайд 2

ВВЕДЕНИЕ Цель даталогического проектиро-вания (ДЛМ) заключается в создании модели, которая отображает

ВВЕДЕНИЕ

Цель даталогического проектиро-вания (ДЛМ) заключается в создании модели, которая отображает логи-ческие

связи между элементами данных безотносительно к их смысловому со-держанию и среде хранения. Эта модель строится в терминах информационных единиц, предусмотренных в конкретной СУБД. Последовательность разработки ДЛМ показана на рис. 1, а расшифровка обозначений приводится на слайде 4.
Слайд 3

Нет

Нет

Слайд 4

Расшифровка обозначений на рисунке 1

Расшифровка обозначений на рисунке 1

 

Слайд 5

 

Слайд 6

На выбор проектных решений самое непо-средственное влияние оказывает специфи-ка предметной области,

На выбор проектных решений самое непо-средственное влияние оказывает специфи-ка предметной области,

отражённая в ИЛМ. Результатом даталогического проек-тирования является описание логической структуры БД на языке описания данных. В спроектированной логической структуре БД должны быть определены все инфор-мационные единицы и связи между ними, заданы имена информационных единиц, их тип и количественные характеристики.
Слайд 7

1. Подход к даталогическому про- ектированию и определение состава БД Для

1. Подход к даталогическому про- ектированию и определение состава БД

Для любой

предметной области суще-ствует множество проектных решений её отображения в ДЛМ. Методика проекти-рования должна обеспечивать выбор наиболее подходящего проектного реше-ния. Минимальная логическая единица данных для всех СУБД семантически одинакова.
Слайд 8

Связи между объектами предметной об-ласти, отражённые в ИЛМ, могут отобра-жаться в

Связи между объектами предметной об-ласти, отражённые в ИЛМ, могут отобра-жаться в

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

В этом случае в ДЛМ вводятся дополни-тельные элементы, отображающие эту связь.

В этом случае в ДЛМ вводятся дополни-тельные элементы, отображающие эту связь.

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

При переходе от ИЛМ к ДЛМ следует иметь в виду, что

При переходе от ИЛМ к ДЛМ следует иметь в виду, что

ИЛМ включает в себя всю информацию, необходимую и доста-точную для проектирования БД. Но это не означает, что все свойства, зафиксирован-ные в ИЛМ, должны в явном виде отра-жаться в ДЛМ. Прежде, чем строить ДЛМ, необходимо решить, какая информация будет храниться в БД. Например, ИЛМ мо-жет содержать вычисляемые показатели, но вовсе не обязательно хранить их в БД.
Слайд 11

Один из подходов к определению состава показателей, хранимых в БД, основан

Один из подходов к определению состава показателей, хранимых в БД, основан

на принципе синтезирования: в БД долж-ны храниться только исходные показатели, а все производные показатели должны вы-числяться в момент выполнения запроса. Этот принцип имеет следующие достоин-ства: 1) простота и однозначность в приня-тии решения о том, «что хранить» в БД; 2) отсутствие явного дублирования инфор-мации; 3) потенциальная возможность по-лучить любой расчётный показатель.
Слайд 12

Несмотря на эти достоинства, в каждом конкретном случае нужно оценивать целе-сообразность

Несмотря на эти достоинства, в каждом конкретном случае нужно оценивать целе-сообразность

хранения вычисляемых пока-зателей в БД с учётом частоты использо-вания этих показателей.
При отображении объекта в БД иденти-фикатор объекта будет атрибутом, который в большинстве случаев используется для однозначной идентификации объекта. Од-нако может появиться необходимость вве-дения искусственных идентификаторов или кодов. Это нужно, когда:
Слайд 13

в предметной области наблюдается омо-нимия, например, среди студентов могут быть полные

в предметной области наблюдается омо-нимия, например, среди студентов могут быть

полные тёзки. В этом случае для обеспечения однозначной идентификации объектов необ-ходимо использовать коды;
если объект участвует во многих связях, то для идентификации связи удобнее исполь-зовать короткий код объекта, нежели длинный идентификатор объекта;
если естественный идентификатор может со временем изменяться, то при отсутствии кода это может вызвать проблемы с поиском нужных сведений.
Слайд 14

2. Метод проектирования реляционной БД на основе ИЛМ Рассмотрим метод проектирования

2. Метод проектирования реляционной БД на основе ИЛМ

Рассмотрим метод проектирования

реляци-онной БД, основанной на анализе ИЛМ и переходе от неё к отношениям ДЛМ. Этот метод является достаточно простым и на-глядным и в то же время даёт хорошие ре-зультаты. Для перехода от ИЛМ к реля-ционной ДЛМ используются следующие правила, в которых идентификаторы объек-тов обозначены через ИО1, ИО2, ИО3, а их свойства – через С1, С2 и т.д.
Слайд 15

2.1. Для каждого простого объекта и его еди-ничных свойств строится отношение,

2.1. Для каждого простого объекта и его еди-ничных свойств строится отношение,

ат-рибутами которого являются идентифи-катор объекта и реквизиты, соответству-ющие каждому из единичных свойств:

ИО1

С1

С2

С3

ИЛМ

R1(ИО1, С1, С2, С3)

ДЛМ

Слайд 16

2.2. Если у объекта имеются множественные свойства, то каждому из них

2.2. Если у объекта имеются множественные свойства, то каждому из них

ставится в соот-ветствие отдельное отношение. Ключом этого отношения будет идентификатор соответству-ющего объекта и реквизит, отражающий множественное свойство:

С4

С1

R1(ИО1, С1, С2)

R2(ИО1, С3)

R3(ИО1, С4)

Слайд 17

2.3. Если между объектом и его свойством имеется условная связь (условное

2.3. Если между объектом и его свойством имеется условная связь (условное

свойство), то при отображении в ДЛМ возможны следую-щие варианты:
а) если многие из объектов обладают услов-ным свойством, то его можно хранить в БД так же, как и обычное свойство;
б) если только незначительное число объек-тов обладает условным свойством, то можно выделить отношение, которое будет включать идентификатор объекта и атрибут, соответст-вующий условному свойству.
Слайд 18

Это отношение будет содержать столько строк, сколько объектов имеют условное свойство:

Это отношение будет содержать столько строк, сколько объектов имеют условное свойство:

R1(ИО1,

С1, С2)
или
R1(ИО1, С1)
R1(ИО1, С2)
Слайд 19

2.4. Если объект имеет составное свойство С, то оно представляется в

2.4. Если объект имеет составное свойство С, то оно представляется в

отношении набором атрибутов С1, С2, соответствующих элемен-там составного свойства:

С

R1(ИО1, С1, С2, С3)

Слайд 20

2.5. Если между объектами имеется степень связи 1:1, то ДЛМ определяется

2.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)

Слайд 24

2.6. Если между объектами имеется степень связи 1:М и класс принадлежности

2.6. Если между объектами имеется степень связи 1:М и класс принадлежности

много-связного объекта является обязательным, то независимо от класса принадлежности односвязного объекта ДЛМ задаётся двумя отношениями – по одному для каждого объекта. Отношение, соответствующее мно-госвязному объекту можно дополнить ат-рибутом, являющимся идентификатором (ключом) односвязного объекта:
Слайд 25

R1(ИО1, С1) R2( ИО2, С2, ИО1) Рисунок к п. 2.6, когда

R1(ИО1, С1)

R2(

ИО2, С2, ИО1)
Рисунок к п. 2.6, когда степень связи имеет

вид 1:М, а класс принадлежности многосвязного объекта является обязательным
Слайд 26

Если класс принадлежности многосвязного объекта является необязательным, то ДЛМ задаётся тремя

Если класс принадлежности многосвязного объекта является необязательным, то ДЛМ задаётся тремя

отношениями – по одному для каждого объекта и одно для отображе-ния связи между объектами. Связь объек-тов задаётся атрибутами, являющимися идентификаторами (ключами) объектов:

R1(ИО1, С1)

R2(ИО2, С2)

R3(ИО1, ИО2)

Слайд 27

2.7. Если между объектами предметной об-ласти имеется степень связи М:М, то

2.7. Если между объектами предметной об-ласти имеется степень связи М:М, то

ДЛМ задаётся тремя отношениями независимо от класса принадлежности объектов:

R1(ИО1, С1)

R2(ИО2, С2)

R3(ИО1, ИО2)

Слайд 28

2.8. Каждому агрегированному объекту, имею-щемуся в предметной области, в ДЛМ соот-ветствует

2.8. Каждому агрегированному объекту, имею-щемуся в предметной области, в ДЛМ соот-ветствует

отдельное отношение. Атрибутами этого отношения будут идентификаторы всех объектов, входящих в агрегированный объект, а также свойства этого объекта:

R1(ИО1, ИО2, ИО3, С1, С2)

Слайд 29

2.9. При отображении обобщённых объектов возможны разные решения. Во-первых, всему обобщённому

2.9. При отображении обобщённых объектов возможны разные решения.
Во-первых, всему обобщённому

объекту может быть поставлено в соответствие одно отношение.
Во-вторых, каждой категории объектов нижнего уровня ставится в соответствие отдельное отношение.
В первом случае атрибутами отношения будут все единичные свойства, присущие объ-ектам хотя бы одной категории плюс иденти-фикатор объекта.
Слайд 30

Во втором случае каждое отношение включает в себя идентификатор объекта, те

Во втором случае каждое отношение включает в себя идентификатор объекта, те

свойства, ко-торые присущи объектам данной категории, а также свойства, которыми обладают родовые объекты, стоящие выше его по иерархии:
Кроме рассмотренных двух случаев возможны и комбини-рованные варианты.

R1(ИО1, С1, С2, С3, С4, С5, С6, С7)

или

R1(ИО1, С1, С2, С4, С5)

R1(ИО1, С1, С2, С6, С7)

Слайд 31

2.10. Составной объект, для которого характер-но наличие связи «целое-часть», может быть

2.10. Составной объект, для которого характер-но наличие связи «целое-часть», может быть

отображён в ДЛМ по-разному. Если рассматри-ваемая связь реализована на однородном мно-жестве объектов, то для отображения связи в этом случае можно использовать два отноше-ния. Первое из них будет содержать информа-цию о самих объектах, а второе – информацию о связи между ними, а также дополнительную информацию, характеризующую эту связь. В большинстве случаев для построения ДЛМ можно использовать рекомендации правила 6.
Слайд 32

2.11. В некоторых случаях одних объектов (сущностей) и связей может оказаться

2.11. В некоторых случаях одних объектов (сущностей) и связей может оказаться

недо-статочно для всестороннего моделирования предметной области. Один из таких случаев возникает тогда, когда экземпляры некоторой сущности должны играть разные роли в дея-тельности организации. Например, предполо-жим, что для кафедры института необходимо хранить информацию о процессе подготовки научных кадров. Различают две категории объектов в этом процессе: преподаватели и аспиранты.
Слайд 33

И те и другие являются научными кадрами, но играют разные роли

И те и другие являются научными кадрами, но играют разные роли

в процессе подготовки научных кадров: преподаватели передают свои знания, а аспиранты приобретают эти знания.
С учётом указанных ролей диаграмма ER-типа будет иметь следующий вид:
Слайд 34

При разработке ДЛМ можно следовать такому правилу. Исходная сущность представляется одним

При разработке ДЛМ можно следовать такому правилу. Исходная сущность представляется одним

отношением, причём ключ сущности служит первичным ключом. Ролевые объекты м связи, их соединяющие, представляются в ДЛМ таким числом отношений, которое определяет-ся ранее описанными правилами, причём каж-дая роль трактуется как обычная сущность. Согласно этому правилу для нашего примера ДЛМ задаётся тремя отношениями:
R1(НК,…) R2(НП,…) R3(НА,…, НП)
Слайд 35

 

Слайд 36

2.12. До сих пор в ИЛМ присутствовали связи только между парами

2.12. До сих пор в ИЛМ присутствовали связи только между парами

объектов. Но могут воз-никнуть и такие ситуации, в которых между объектами существуют связи более высокого порядка. Например, рассмотрим ситуацию приёма экзаменов преподавателями в группах, представив её в виде диаграмм ER-экземп-ляров и ER-типа (на рисунке 3 следующего слайда введены следующие обозначения: НП – номер преподавателя, ИЭ – идентификатор экзамена, ШГ – шифр группы, M:N, M:L – связи более высокого порядка).
Слайд 37

П1 П2 ПРЕПОДАВАТЕЛЬ ГРУППА ЭКЗАМЕН Э1 Э3 Э2 (Мат. анализ) (Базы

П1

П2

ПРЕПОДАВАТЕЛЬ

ГРУППА

ЭКЗАМЕН

Э1

Э3

Э2

(Мат. анализ)

(Базы данных)

(Информатика)

МТМ-б-о-121

ПМИ-б-о-111

Рисунок 2 - Диаграмма ER-экземпляров

ЭКЗАМЕН

ПРЕПОДАВАТЕЛЬ

ГРУППА

ИЭ…

НП…

ШГ…

м

N

L

GHBYBVFTN

ПРИНИМАЕТ

Рисунок 3 -

Диаграмма ER-типа
Слайд 38

В случае трёхсторонних связей в ИЛМ датало-гическая модель состоит из четырёх

В случае трёхсторонних связей в ИЛМ датало-гическая модель состоит из четырёх

отноше-ний: по одному для каждой сущности, причём ключ каждой сущности должен служить пер-вичным ключом для соответствующего от-ношения, и одно отношение для связи сущнос-тей. Отношение, порождённое связью, будет иметь среди своих атрибутов ключи сущностей от каждой сущности. Для рассматриваемого примера ДЛМ состоит из таких отношений:
R1(НП,…) R2(ИЭ,…)
R3(ШГ,…) R4(НП, ИЭ, ШГ,…)
Слайд 39

При наличии n-сторонней связи требуется n+1 отношение: n отношений для сущнос-тей

При наличии n-сторонней связи требуется n+1 отношение: n отношений для сущнос-тей

и одно отношение для связи. Полу-ченная таким образом ДЛМ содержит от-ношение для связи, которое напоминает результат применение правила 8 для агре-гированного объекта. Это не случайно, по-скольку ИЛМ отображает один процесс, в который вовлечено несколько объектов, то есть предметную область можно тракто-вать как агрегированный объект, именуе-мый ПРИЁМОМ ЭКЗАМЕНОВ.
Слайд 40

3. ПРИМЕР ПРОЕКТИРОВАНИЯ РБД НА ОСНОВЕ ИЛМ и ДЛМ Возьмём в

3. ПРИМЕР ПРОЕКТИРОВАНИЯ РБД НА ОСНОВЕ ИЛМ и ДЛМ

Возьмём в качестве

предметной области жителей некоторого города и спроекти-руем простейшую реляционную базу дан-ных, в которой будут храниться сведения, представляющие интерес для налоговой инспекции. Проектирование начинается с разработки ИЛМ, которая включает в себя компоненты, изображённые на ри-сунке 1 предыдущей темы.
Слайд 41

3.1. Описание объектов и связей между ними Объектами, представляющими интерес, будут

3.1. Описание объектов и связей между ними

Объектами, представляющими интерес, будут ЖИТЕЛЬ,

КВАРТИРА, ТЕЛЕФОН, ДОХОД. Опишем каждый из них и связи между ними.

ЖИТЕЛЬ

Nom

FIO

Rdate

Pol

SumD

s

s

s

D

D

Порядковый номер жителя

Фамилия, имя, отчество

Дата рождения

Пол: М – мужской, Ж - женский

Общий доход

Слайд 42

Категория квартиры П – приватизирована Н - не приватизирована К - коммунальная

Категория квартиры
П – приватизирована
Н - не приватизирована
К - коммунальная

Слайд 43


Слайд 44

Связи между объектами отражаются на диаграмме ER-типа: ЖИТЕЛЬ КВАРТИРА ТЕЛЕФОН ДОХОД

Связи между объектами отражаются на диаграмме ER-типа:

ЖИТЕЛЬ

КВАРТИРА

ТЕЛЕФОН


ДОХОД

Nom…

Adr…

Ntel…

Id…

ЖИВЁТ

ИМЕЕТ_Т

ИМЕЕТ_Д

Слайд 45

3.2. Лингвистические отношения В лингвистических отношениях должно быть дано толкование используемых

3.2. Лингвистические отношения

В лингвистических отношениях должно быть дано толкование используемых в

ИЛМ терми-нов и понятий, например:
Nom – уникальный номер жителя данного города, в качестве которого используется целое число;
Adr – адрес жителя; задаётся указанием ули-цы, номера дома (корпуса) и квартиры;
Source – обозначение источника дохода: Пенсия1 – пенсия по старости; Пособие1 – пособие на ребёнка; Стипендия1 – повышенная стипендия; Работа1 – работа в банке и т.д.
Money – размер дохода в рублях.
Слайд 46

3.3. Алгоритмические связи показателей Из всех показателей, отражённых в ИЛМ, ал-горитмически

3.3. Алгоритмические связи показателей

Из всех показателей, отражённых в ИЛМ, ал-горитмически связанным

является общий до-ход (SumD). Его вычисление описывается сле-дующим графом взаимосвязи показателей:

Money

Money

Money

ДОХОД



Слайд 47

3.4. Описание информационных потребностей пользователей Здесь должны быть определены все запросы,

3.4. Описание информационных потребностей пользователей

Здесь должны быть определены все запросы, которые

будут поступать от пользователей БД, например:
вывести список всех жителей с указанием общего дохода;
вывести список жителей, у которых общий доход не меньше облагаемого минимума;
подсчитать налоги отдельных жителей и общую сумму налогов и т.д.
Этот компонент служит основой для раз-работки БД.
Слайд 48

3.5. Ограничения целостности Ограничения целостности используются при разработке БД, чтобы контролировать

3.5. Ограничения целостности

Ограничения целостности используются при разработке БД, чтобы контролировать правильность

данных, вводимых в БД, и кор-ректность вычислений. Например, размер до-хода не должен быть отрицательным, источник дохода должен выбираться из известного списка и т.п. Таким образом, в данном ком-поненте ДЛМ формулируются условия, ко-торым должны удовлетворять отдельные пока-затели и группы показателей, чтобы инфор-мация, хранимая в БД, имела смысл.
Слайд 49

3.6. Описание структуры БД на основе языка ДЛМ Будем хранить в

3.6. Описание структуры БД на основе языка ДЛМ

Будем хранить в этой

БД все показатели, в том числе и вычисляемый показатель SumD, поскольку его значение требуется при выполнении многих запросов. Введём теперь отношения, включаемые в БД. Для этой цели применим соот-ветствующие правила из п.2 к каждой паре связанных объектов, изображённых на диаграмме ER-типа (рисунок п. 3.1).
Слайд 50

Согласно правилу 6 связанные объекты ЖИТЕЛЬ-КВАРТИРА представляются двумя отношениями: PERSON’(Nom,…, Adr)

Согласно правилу 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-типа или концептуальной мо-дели и зачастую ограничиваются изображением логической модели БД в некоторой автомати-зированной среде проектирования БД.