Методология проектирования БД - физическое проектирование

Нажмите для полного просмотра!

Методология проектирования БД - физическое проектирование, слайд №2

Методология проектирования БД - физическое проектирование, слайд №3

Методология проектирования БД - физическое проектирование, слайд №4

Методология проектирования БД - физическое проектирование, слайд №5

Методология проектирования БД - физическое проектирование, слайд №6

Методология проектирования БД - физическое проектирование, слайд №7

Методология проектирования БД - физическое проектирование, слайд №8

Методология проектирования БД - физическое проектирование, слайд №9

Методология проектирования БД - физическое проектирование, слайд №10

Методология проектирования БД - физическое проектирование, слайд №11

Методология проектирования БД - физическое проектирование, слайд №12

Методология проектирования БД - физическое проектирование, слайд №13

Методология проектирования БД - физическое проектирование, слайд №14

Методология проектирования БД - физическое проектирование, слайд №15

Методология проектирования БД - физическое проектирование, слайд №16

Методология проектирования БД - физическое проектирование, слайд №17

Методология проектирования БД - физическое проектирование, слайд №18

Методология проектирования БД - физическое проектирование, слайд №19

Методология проектирования БД - физическое проектирование, слайд №20

Методология проектирования БД - физическое проектирование, слайд №21

Методология проектирования БД - физическое проектирование, слайд №22

Методология проектирования БД - физическое проектирование, слайд №23

Методология проектирования БД - физическое проектирование, слайд №24

Методология проектирования БД - физическое проектирование, слайд №25

Методология проектирования БД - физическое проектирование, слайд №26

Методология проектирования БД - физическое проектирование, слайд №27

Методология проектирования БД - физическое проектирование, слайд №28

Методология проектирования БД - физическое проектирование, слайд №29

Методология проектирования БД - физическое проектирование, слайд №30

Методология проектирования БД - физическое проектирование, слайд №31

Методология проектирования БД - физическое проектирование, слайд №32

Методология проектирования БД - физическое проектирование, слайд №33

Методология проектирования БД - физическое проектирование, слайд №34

Методология проектирования БД - физическое проектирование, слайд №35

Методология проектирования БД - физическое проектирование, слайд №36

Методология проектирования БД - физическое проектирование, слайд №37

Методология проектирования БД - физическое проектирование, слайд №38

Методология проектирования БД - физическое проектирование, слайд №39

Методология проектирования БД - физическое проектирование, слайд №40

Методология проектирования БД - физическое проектирование, слайд №41

Методология проектирования БД - физическое проектирование, слайд №42

Методология проектирования БД - физическое проектирование, слайд №43

Методология проектирования БД - физическое проектирование, слайд №44

Методология проектирования БД - физическое проектирование, слайд №45

Методология проектирования БД - физическое проектирование, слайд №46

Методология проектирования БД - физическое проектирование, слайд №47

Методология проектирования БД - физическое проектирование, слайд №48

Методология проектирования БД - физическое проектирование, слайд №49

Методология проектирования БД - физическое проектирование, слайд №50

Методология проектирования БД - физическое проектирование, слайд №51

Методология проектирования БД - физическое проектирование, слайд №52

Методология проектирования БД - физическое проектирование, слайд №53

Методология проектирования БД - физическое проектирование, слайд №54

Методология проектирования БД - физическое проектирование, слайд №55

Методология проектирования БД - физическое проектирование, слайд №56

Методология проектирования БД - физическое проектирование, слайд №57

Методология проектирования БД - физическое проектирование, слайд №58

Методология проектирования БД - физическое проектирование, слайд №59

Методология проектирования БД - физическое проектирование, слайд №60

Методология проектирования БД - физическое проектирование, слайд №61

Методология проектирования БД - физическое проектирование, слайд №62

Методология проектирования БД - физическое проектирование, слайд №63

Методология проектирования БД - физическое проектирование, слайд №64

Методология проектирования БД - физическое проектирование, слайд №65

Методология проектирования БД - физическое проектирование, слайд №66

Методология проектирования БД - физическое проектирование, слайд №67

Методология проектирования БД - физическое проектирование, слайд №68

Методология проектирования БД - физическое проектирование, слайд №69

Методология проектирования БД - физическое проектирование, слайд №70

Методология проектирования БД - физическое проектирование, слайд №71

Методология проектирования БД - физическое проектирование, слайд №72

Методология проектирования БД - физическое проектирование, слайд №73

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему Методология проектирования БД - физическое проектирование. Доклад-сообщение содержит 73 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1

Описание слайда:

Московский государственный университет экономики, статистики и информатики (МЭСИ) Начальник отдела НИЧ, к.э.н., доцент Д.Г. Корнеев 2010 год

Слайд 2

Описание слайда:

Слайд 3

Описание слайда:

Слайд 4

Описание слайда:

Слайд 5

Описание слайда:

Слайд 6

Описание слайда:

Слайд 7

Описание слайда:

Слайд 8

Описание слайда:

Слайд 9

Описание слайда:

Слайд 10

Описание слайда:

Слайд 11

Описание слайда:

Слайд 12

Описание слайда:

Слайд 13

Описание слайда:

Слайд 14

Описание слайда:

Слайд 15

Описание слайда:

Слайд 16

Описание слайда:

Слайд 17

Описание слайда:

Слайд 18

Описание слайда:

Слайд 19

Описание слайда:

Слайд 20

Описание слайда:

Слайд 21

Описание слайда:

Слайд 22

Описание слайда:

Слайд 23

Описание слайда:

Слайд 24

Описание слайда:

Слайд 25

Описание слайда:

Слайд 26

Описание слайда:

Слайд 27

Описание слайда:

Слайд 28

Описание слайда:

Слайд 29

Описание слайда:

Слайд 30

Описание слайда:

Слайд 31

Описание слайда:

Слайд 32

Описание слайда:

Слайд 33

Описание слайда:

Слайд 34

Описание слайда:

Слайд 35

Описание слайда:

Этап Определение требований поддержки целостности данных Цель Определение ограничений, налагаемых в представлениях пользователей требованием сохранения целостности данных. Ограничения целостности данных представляют собой такие ограничения, которые вводятся с целью предотвратить помещение в базу противоречивых данных. Отметим, что, хотя в конкретных СУБД ФУНКЦИИ КОНТРОЛЯ целостности могут как поддерживаться, так и не поддерживаться, в данном случае это не будет нас интересовать. На этом этапе мы занимаемся проектированием только на верхнем уровне, где рассмотрение вопросов целостности данных является обязательным условием, не связанным с конкретными аспектами реализации.

Слайд 36

Описание слайда:

Этап Определение требований поддержки целостности данных Полное и точное отражение представления пользователя мы сможем получить ТОЛЬКО после определения ограничений, необходимых с ТОЧКИ зрения сохранения целостности данных. Здесь мы обсудим пять типов ограничений целостности данных: • обязательные данные; • ограничения для доменов атрибутов; • целостность сущностей; • ссылочная целостность; • требования данного предприятия.

Слайд 37

Описание слайда:

Этап Определение требований поддержки целостности данных Обязательные дaнные: Некоторые атрибуты всегда должны содержать одно из допустимых значений. Другими словами, эти атрибуты не могут иметь пустого (NULL) значения. Так, каждый работник должен: занимать ту или иную должность (например, «руководитель», «начальник отдела» или «бухгалтер» и т.д.). Эти ограничения должны фиксироваться при занесении сведений об атрибуте в словарь данных.

Слайд 38

Описание слайда:

Этап Определение требований поддержки целостности данных Ограничения для доменов атрибутов. Каждый атрибут имеет домен, представляющий собой набор его допустимых значений. Например, атрибут "пол" может содержать одно из двух допустимых значений - "М" или "Ж", поэтому его домен состоит из двух символьных строк длиной в один символ, содержащих указанные значения. Данные ограничения устанавливаются при определении доменов атрибутов, присутствующих в модели данных.

Слайд 39

Описание слайда:

Этап Определение требований поддержки целостности данных Целостность сущностей: Первичный ключ любой сущности не может содержать пустого значения. Например, каждая строка отношения Staff должна содержать уникальное значение атрибута первичного ключа; в данном случае это - атрибут Staf_No. Подобные ограничения должны учитываться при определении первичных ключей для сущностей каждого типа.

Слайд 40

Описание слайда:

Этап Определение требований поддержки целостности данных Ссылочная целостность Внешний ключ связывает каждую строку дочернего отношения с той строкой родительского отношения, которая содержит это же значение соответствующего потенциального ключа. Понятие ссылочной целостности означает, что если внешний ключ содержит некоторое значение, то оно обязательно должно присутствовать в потенциальном ключе одной из строк родительского отношения.

Слайд 41

Описание слайда:

Этап Определение требований поддержки целостности данных Например, атрибут Branch_No отношения Staff связывает данные о каждом из работников со строкой в отношении Branch, соответствующей тому отделению предприятия, в котором он работает. Если поле Branch_No не пусто, оно должно содержать допустимое значение, присутствующее в атрибуте Branch_No одной из строк отношения Branch. В противном случае окажется, что работник трудится в несуществующем отделении.

Слайд 42

Описание слайда:

Этап Определение требований поддержки целостности данных Существует несколько важных моментов, связанных с использованием внешних ключей. Во-первых, следует проанализировать, допустимо ли использование во внешних ключах пустых значений. Например, имеет ли смысл сохранять сведения о работнике, если не задан номер отделения предприятия, в котором он работает? Вопрос не в проверке существования заданного номера отделения, а в том, обязательно ли этот номер должен указываться. В общем случае, если участие дочернего отношения в связи является тотальным, то рекомендуется запрещать использование пустых значений в соответствующем внешнем ключе. В то же время, если участие дочернего отношения в связи является частичным, то помещение пустых значений в атрибут внешнего ключа должно быть разрешено.

Слайд 43

Описание слайда:

Этап Определение требований поддержки целостности данных Следующая проблема связана с организацией поддержки ссылочной целостности. Реализация этой поддержки осуществляется посредством задания ограничений существования, определяющих условия, при которых может вставляться, обновляться или удаляться каждое значение потенциального или внешнего ключа. Рассмотрим связь Staff manages Property типа 1:М. Первичный ключ отношения Staff (атрибут Staff_No) является внешним ключом отношения Property.

Слайд 44

Описание слайда:

Этап Определение требований поддержки целостности данных Рассмотрим следующие ситуации: Случай 1. Вставка новой строки в дочернее отношение (Property). Для обеспечения ссылочной целостности необходимо убедиться, что значение атрибута внешнего ключа Staff_No новой строки отношения Property равно пустому значению либо некоторому конкретному значению, присутствующему в одной из строк отношения Staff. Случай 2. Удаление строки из дочернего отношения (Property). При удалении строки из дочернего отношения никаких нарушений ссылочной целостности не происходит.

Слайд 45

Описание слайда:

Этап Определение требований поддержки целостности данных Случай 3. Обновление внешнего ключа в строке дочернего отношения (Property). Этот случай подобен случаю 1. Для сохранения ссылочной целостности необходимо убедиться, что атрибут Staff_No в обновленной строке отношения Property содержит либо пустое значение, либо некоторое конкретное значение, присутствующее в одной из строк отношения Staff. Случай 4. Вставка строки в родительское отношение (Staff). Вставка строки в родительское отношение (Staff) не может вызвать нарушения ссылочной целостности. Добавленная строка просто становится родительским объектом, не имеющим дочерних объектов. В данном случае это означает, что новый работник еще не отвечает ни за какие объекты недвижимости.

Слайд 46

Описание слайда:

Этап Определение требований поддержки целостности данных Случай 5. Удаление строки из родительского отношения (Staff). При удалении строки из родительского отношения ссылочная целостность будет нарушена в том случае, если в дочернем отношении будут существовать строки, ссылающиеся на удаленную строку родительского отношения. Другими словами, ссылочная целостность будет нарушена, если удаленный работник отвечал за один или больше объектов недвижимости. В этом случае может быть использована однэ. из следующих стратегий.

Слайд 47

Описание слайда:

Этап Определение требований поддержки целостности данных NO ACTION. Удаление строки из родительского отношения запрещается, если в дочернем отношении существует хотя бы одна ссылающаяся на нее строка. В нашем случае это звучит так: "Нельзя удалить сведения о работнике, отвечающем в настоящий момент хотя бы за один объект недвижимости" . CASCADE. При удалении строки из родительского отношения автоматически удаляются все ссылающиеся на нее строки дочернего отношения. Если любая из удаляемых строк дочернего отношения выступает в качестве родительской стороны в некоторой другой связи, то операция удаления применяется ко всем строкам дочернего отношения этой СВЯЗИ. Другими словами, удаление строки родительского отношения автоматически распространяется на любые дочерние отношения. В нашем случае это звучит так: "Удаление работника автоматически влечет за собой удаление сведений обо всех объектах недвижимости, которыми он занимался". Очевидно, что в данном примере подобная стратегия неприемлема.

Слайд 48

Описание слайда:

Этап Определение требований поддержки целостности данных SET NULL. При удалении строки из родительского отношения во всех ссылающихся на нее строках дочернего отношения в атрибут внешнего ключа записывается пустое значение. Следовательно, удаление строк из родительского отношения вызовет занесение пустого значения. в соответствующий атрибут строк дочернего отношения. В нашем случае это звучит так: "При удалении работника все объекты недвижимости, которыми он занимался, остаются без отвечающего за них работника". Эта стратегия может использоваться только в тех случаях, когда в атрибут внешнего ключа дочернего отношения разрешается помещать пустые значения.

Слайд 49

Описание слайда:

Этап Определение требований поддержки целостности данных SET DEFAULT. При удалении строки из родительского отношения в атрибут внешнего ключа всех ссылающихся на нее строк дочернего отношения автоматически помещается значение, указанное для этого атрибута как значение по умолчанию. Таким образом, удаление строки из родительского отношения вызывает помещение принимаемого по умолчанию значения в атрибут внешнего ключа всех строк дочернего отношения, ссылающихся на удаленную строку.

Слайд 50

Описание слайда:

Этап Определение требований поддержки целостности данных В нашем случае это будет звучать так: "При удалении работника все объекты недвижимости, которыми он занимался, передаются некоторому другому работнику (например, руководителю отделения)". Эта стратегия применима только в тех случаях, когда атрибуту внешнего ключа дочернего отношения назначено некоторое значение, принимаемое по умолчанию. • NO СНЕСК. При удалении строки из родительского отношения никаких действий по сохранению ссылочной целостности данных не предпринимается.

Слайд 51

Описание слайда:

Этап Определение требований поддержки целостности данных Случай 6. Обновление первичного ключа в строке родительского отношения(Statt). Если значение первичного ключа некоторой строки родительского отношения будет обновлено, нарушение ссылочной целостности будет иметь место в том случае, если в дочернем отношении существуют строки, ссылающиеся на исходное значение первичного ключа. В нашем случае это значит, что работник, для которого было выполнено обновление, в данный момент отвечал за один или более объектов недвижимости. Для сохранения ссылочной целостности может использоваться любая из описанных выше стратегий. При использовании стратегии CASCADE обновление значения первичного ключа в строке родительского отношения будет отображено в любой строке дочернего отношения, ссылающейся на данную строку (каскадным образом).

Слайд 52

Описание слайда:

Этап Учет требования данного предприятия В заключение требуется проанализировать ограничения, называемые ограничениями предприятия (или бизнес-правилами). Например, обновление сущностей может регламентироваться принятыми на предприятии правилами, описывающими методы выполнения транзакций, связанных с подобными обновлениями. В нашем примере, в компании DreamHome может быть принято правило, запрещающее одному работнику одновременно заниматься более чем десятью объектами недвижимости. Документирование всех ограничений цел0стностu данных. Поместите сведения обо всех установленных ограничениях целостности данных в словарь данных. Они потребуются на этапе физической реализации базы БД.

Слайд 53

Описание слайда:

Взаимосвязь между логическими моделями данных и диаграммами потоков данных Логическая модель данных отображает структуру сохраняемых данных предприятия. Диаграмма потоков данных (Data Flow Diagram - DFD) отображает перемещение данных в пределах предприятия и помещение их в хранилища информации. Все атрибуты, которые сохраняются на предприятии, должны быть объявлены в одном из типов сущностей и, вероятно, найти свое место в потоках данных, перемещающихся в пределах предприятия. Если обе эти технологии используются для моделирования требований пользователей, каждая из них может применяться для контроля согласованности и полноты другой. Правила, которые определяют отношения между этими двумя технологиями, следующие: • каждое хранилище данных должно представлять все множество типов сущностей; • атрибуты в потоках данных должны принадлежать сущности того или иного типа.

Слайд 54

Описание слайда:

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

Слайд 55

Описание слайда:

Этап. Создание и проверка глобальной логической модели данных Проверка выполняется с использованием тех же методов, которые применялись при выполнении предыдущих этапов логического проектирования локальных моделей. Однако проведение нормализации потребуется только в том случае, если в процессе слияния были внесены изменения в состав отдельных типов сущностей. Аналогично, проверка возможности выполнения транзакций выполняется только для тех областей модели, которые были подвергнуты изменениям в ходе слияния. В больших системах подобный подход позволяет существенно сократить объем требуемых повторных проверок.

Слайд 56

Описание слайда:

Этап. Создание и проверка глобальной логической модели данных Хотя каждая отдельная логическая модель данных предполагается корректной, полной и непротиворечивой, любая из них отражает лишь восприятие системы отдельным пользователем или группой пользователей. Другими словами, каждая модель отражает не функции предприятия, а лишь представление о функциях предприятия отдельных его работников. Поэтому любая из этих моделей является неполной. А это означает, что между отдельными моделями в полном наборе представлений могут существовать несовместимость и взаимное перекрытие. Следовательно, при слиянии локальных моделей данных в единую глобальную модель придется прилагать усилия для устранения конфликтов между отдельными представлениями и принимать во внимание их возможное перекрытие.

Слайд 57

Описание слайда:

Этап. Создание и проверка глобальной логической модели данных Процедуру слияния можно считать самой важной в ходе логического проектирования базы данных, поскольку с ее помощью создается представление о предприятии, не зависящее от любых конкретных пользователей, бизнес-процессов или приложений. Данный этап предусматривает выполнение следующих действий. • Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных. • Этап 3.2. Проверка глобальной логической модели данных. • Этап 3.3. Проверка возможностей расширения модели в будущем. • Этап 3.4. Создание окончательного варианта диаграммы "сущность-связь". • Этап 3.5. Обсуждение глобальной логической модели данных с пользователями.

Слайд 58

Описание слайда:

Этап 3.1. Слияние локальных логических моделей данных Цель Объединить отдельные локальные логические модели данных в единую глобальную логическую модель данных предприятия. В небольших системах, насчитывающих два-три пользовательских представления с незначительным количеством типов сущностей и связей, задача сравнения локальных моделей с последующим слиянием и устранением любых возможных противоречий является относительно несложной. Однако, в крупных системах потребуется использовать более систематический подход. Ниже описывается один из подобных подходов, который можно использовать для выполнения слияния локальных моделей и разрешения любых возникающих при этом проблем.

Слайд 59

Описание слайда:

Этап 3.1. Слияние локальных логических моделей данных Предлагаемый подход предусматривает выполнение следующих действий: 1. Анализ имен сущностей и их первичных ключей. 2. Анализ имен связей. 3. Слияние общих сущностей из отдельных локальных моделей. 4. Включение (без слияния) сущностей, уникальных для каждого локального представления. 5. Слияние общих связей из отдельных локальных моделей. 6. Включение (без слияния) связей, уникальных для каждого локального представления. 7. Проверка на наличие пропущенных сущностей и связей. 8. Проверка корректности внешних ключей. 9. Проверка соблюдения ограничений целостности. 10. Выполнение чертежа глобальной логической модели данных. 11. Обновление документации

Слайд 60

Описание слайда:

Этап 3.1. Слияние локальных логических моделей данных Вероятно, самый простой метод слияния нескольких локальных моделей данных в единую модель состоит в слиянии двух локальных моделей в одну общую модель, с последующим добавлением к ней третьей локальной модели (и т.д.). Процесс добавления к предыдущему результату очередной локальной модели будет продолжаться то тех пор, пока все модели не будут слиты в единую глобальную модель. Этот подход можно считать более простым, чем попытка слить все локальные модели за одну операцию. Очень важно отметить, что, прежде чем приступать к созданию глобального представления информационной модели предприятия, следует убедиться, что каждая из сливаемых локальных логических моделей была создана в полном соответствии с последовательностью действий, предусмотренных первым и вторым этапами разработки, определенными в обсуждаемой методологии проектирования баз данных.

Слайд 61

Описание слайда:

Этап 3.1. Слияние локальных логических моделей данных 1. Анализ имен сущностей и их первичных ключей. Может оказаться полезным предварительно проанализировать имена сущностей, присутствующих в локальных моделях данных, - эти сведения можно найти в словаре данных. Проблемы имеют место в следующих случаях: • если две или более сущностей имеют одно и то же имя, но на самом деле отличаются одна от другой; • если две или более сущностей идентичны, но имеют различные имена. Для выявления возможных проблем следует сравнить между собой составы данных сущностей каждого типа. В частности, обнаружить эквивалентные сущности с различными именами поможет сравнение их первичных ключей. 2. Анализ имен связей. Выполняемые действия аналогичны описанным на предыдущем этапе.

Слайд 62

Описание слайда:

Этап 3.1. Слияние локальных логических моделей данных Слияние общих сущностей из отдельных локальных моделей: Следует проанализировать имена и содержимое сущностей каждого типа, присутствующих в сливаемых логических моделях. Обычно эта процедура включает следующие действия: • слияние сущностей с одинаковыми именами и первичными ключами; • слияние сущностей с одинаковыми именами, но с различными первичными ключами; • слияние сущностей с различными именами, имеющих одинаковые или различные первичные ключи.

Слайд 63

Описание слайда:

Этап 3.1. Слияние локальных логических моделей данных Слияние сущностей с одинаковыми именами и первичными ключами. Как правило, сущности с одним и тем же первичным ключом представляют один и тот же объект реального мира и, следовательно, должны быть слиты. Объединенная сущность будет включать все атрибуты сливаемых сущностей, за исключением дублирующихся. Далее в примере перечислены атрибуты, связанные с двумя сущностями, носящими имя Staff, которые определены в двух различных представлениях, названных Viewl и View2. В обоих случаях первичным ключом является атрибут Staff_No. Слияние этих сущностей осуществляется путем объединения их атрибутов, поэтому в Сводной сущности Staff будут присутствовать все атрибуты исходных сущностей.

Слайд 64

Описание слайда:

Слияние сущностей с одинаковыми именами и первичными ключами. Представление View1 Staff (Staff No, Name, Position, Sex, Salary, Branch_No) Primary Кеу Staff No Foreign Кеу Branch_No references Branch(Branch_No) Представление View2 Staff (Staff No, FName, LName, Address, Branch_No) Primary Кеу Staff No Foreign Кеу Branch_No references Branch(Branch_No) Итоговая сущность Staff Staff (Staff No, FName, LName, Address, Position, Sex, Salary, Branch_No) Primary Key Staff No Foreign Кеу Branch_No references Branch(Branch_No)

Слайд 65

Описание слайда:

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

Слайд 66

Описание слайда:

Представление View1 Представление View1 Staff (Staff_No, Name, Position, Sex, Salary, Branch_No) Primary Кеу Name Alternate Кеу Staff No Foreign Кеу Branch_No references Branch(Branch_No) Представление View2 Staff (Staff No, FName, LNarne, Address, Branch_No) Primary Кеу Staff No Alternate Кеу FName, LNarne Foreign Кеу Branch_No references Branch(Branch_No) Глобальное представление Staff (Staff No, FNarne, LNarne, Address, Position, Sex, Salary, Branch_No) Primary Кеу Staff No Alternate Кеу FName, LNarne Foreign Кеу Branch_No references Branch(Branch_No)

Слайд 67

Описание слайда:

Слияние сущностей с различными именами, имеющих одинаковые или различные первичные ключи. В некоторых случаях можно обнаружить сущности, которые имеют различные имена, но предназначены для одной и той же цели. Подобные эквивалентные сущности можно распознать по их именам, которые будут указывать на их сходное назначение, по их содержанию и по их первичным ключам. Кроме того, их можно распознать по участию в определенных связях. Типичным примером подобной ситуации является наличие в моделях сущностей с названиями Staff (Персонал) и Employee (Работник), которые, по сути, являются эквивалентными и должны быть слиты в единую сущность.

Слайд 68

Описание слайда:

Слияние локальных логических моделей данных 4 Включение (без слияния) сущностей, уникальных для каждого локального представления На предыдущем этапе были выделены все сущности, описывающие подобные объекты. Все остальные сущности просто включаются в глобальную модель без внесения каких-либо изменений. 5. Слияние общих связей из отдельных локальных моделей На этом этапе анализируются имена и назначение каждой из связей во всех представлениях отдельных пользователей. Прежде чем объединять связи, очень важно разрешить любые конфликты, которые могут иметь место между ними, - например, в отношении ограничений участия или кардинальности. Выполняемые на этом этапе действия включают слияние связей с одинаковыми именами и назначением, после чего может потребоваться выполнить слияние связей с различными именами, но имеющих одно и то же назначение.

Слайд 69

Описание слайда:

Включение (без слияния) связей, уникальных для каждого локального представления 6. Включение (без слияния) связей, уникальных для каждого локального представления На предыдущем этапе были выявлены и слиты все связи, имевшие сходное назначение (по определению, эти связи должны существовать между одними и теми же сущностями, которые также должны быть слиты друг с другом). Все оставшиеся связи включаются в глобальную модель без каких-либо изменений.

Слайд 70

Описание слайда:

Проверка на наличие пропущенных сущностей и связей 7. Проверка на наличие пропущенных сущностей и связей Вероятно, одной из самых трудных задач при создании глобальной модели данных является задача выявления пропущенных сущностей и связей между элементами представлений различных пользователей. Если на предприятии существует корпоративная модель данных, она может использоваться для обнаружения сущностей и связей между элементами представлений различных пользователей, которых нет ни в одном из локальных представлений.

Слайд 71

Описание слайда:

Проверка на наличие пропущенных сущностей и связей В то же время, при проведении опросов пользователей конкретного представления в качестве превентивной меры следует попросить их уделить некоторое внимание сущностям и связям, которые, по их мнению, могут существовать в других представлениях. Кроме того, при анализе атрибутов сущностей каждого типа можно попробовать выделить ссылки на сущности, принадлежащие другим пользовательским представлениям. Достаточно часто оказывается, что атрибут, связанный с той или иной сущностью в представлении одного пользователя, соответствует первичному ключу, альтернативному ключу или даже простому, неключевому атрибуту некоторой сущности из другого представления.

Слайд 72

Описание слайда:

Слияние локальных логических моделей данных 8. Проверка корректности внешних ключей На этом этапе может осуществляться слияние различных сущностей и связей, изменение первичных ключей и установка новых связей. Убедитесь, что внешние ключи в дочерних сущностях по-прежнему являются корректными, и в случае необходимости внесите в модель все требуемые изменения. 9. Проверка соблюдения ограничений целостности Убедитесь, что установленные для глобальной логической модели ограничения целостности данных не вступают в противоречие с теми ограничениями, которые были установлены для каждого из пользовательских представлений. Любые конфликты следует устранять посредством проведения консультаций с пользователями.

Слайд 73

Описание слайда:

Этап 3. Проверка возможностей расширения модели в будущем Цель Определение вероятности внесения каких-либо существенных изменений в созданную модель данных в обозримом будущем и оценка того, насколько данная модель приспособлена для этого. Очень важно, чтобы созданная глобальная модель была легко расширяема. Если модель сможет поддерживать только текущие требования, то время ее существования будет весьма ограниченным, а для реализации поддержки новых или изменяющихся требований потребуется прилагать значительные усилия. Необходимо так построить модель, чтобы она была легко расширяема и позволяла реализовать поддержку новых требований с минимальным изменениями в работе уже существующих пользователей. Следовательно, имеет смысл выполнить проверку созданной модели с точки зрения эффективности реализации новых требований, которые могут иметь место в будущем. Однако не следует вносить в модель каких-либо изменений, пока они не будут одобрены пользователями.