Разделы презентаций


Lecture7.ppt

Содержание

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

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

Слайд 1Этапы проектирования БД
Процесс проектирования БД состоит их трех основных этапов:
концептуальное

проектирование;
логическое проектирование;
физическое проектирование.
1. Концептуальное проектирование БД – это процесс создания

высокоуровневой семантической модели для данных, которые присутствуют в определенной предметной области.
Этапы проектирования БДПроцесс проектирования БД состоит их трех основных этапов:концептуальное проектирование;логическое проектирование;физическое проектирование.1. Концептуальное проектирование БД –

Слайд 2Важно, что такая модель никак не зависит от любых аспектов

ее физической реализации:
тип СУБД и вычислительной платформы;
набор прикладных программ;
средства программирования

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

Слайд 32. Логическое проектирование БД – это процесс создания информационной модели

на основе выбранной модели структурной организации данных при их хранении

и обработке.

Это делается без выбора конкретной СУБД и без учета остальных аспектов физической реализации БД.
Логическая модель данных создается путем преобразования концептуальной модели с учетом особенностей выбранной модели организации данных.

2. Логическое проектирование БД – это процесс создания информационной модели на основе выбранной модели структурной организации данных

Слайд 4Важную роль логическая модель данных играет и при эксплуатации (сопровождении)

уже готовой БД.
Эта модель, если ее постоянно поддерживать в актуальном

состоянии, позволяет точно и наглядно представить любые изменения в структуре БД, а также оценить их влияние на прикладное ПО.
3. Физическое проектирование – это процесс принятия решений по реализации проекта разрабатываемой БД.
Важную роль логическая модель данных играет и при эксплуатации (сопровождении) уже готовой БД.Эта модель, если ее постоянно

Слайд 5В случае реляционной БД это означает:
выбор конкретной (целевой) СУБД;
построение процедуры

создания таблиц на жестком диске;
определение методов доступа к данным, чтобы

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

Слайд 6Методология концептуального проектирования БД
Определение типов (классов) сущностей
Определение атрибутов для сущностей
Определение

доменов для атрибутов
Определение потенциальных и первичных ключей
Определение типов связей между

сущностями
Построение ER-диаграммы
Методология концептуального проектирования БДОпределение типов (классов) сущностейОпределение атрибутов для сущностейОпределение доменов для атрибутовОпределение потенциальных и первичных ключейОпределение

Слайд 7При выборе первичного ключа среди нескольких потенциальных ключей наиболее важными

являются следующие факторы:
min набор атрибутов (наилучший вариант – простой ключ

целого типа);
значения min длины;
высокая стабильность (т.е. min вероятность изменения значений);
простота работы для пользователя.
Если нет возможности сделать удачный выбор первичного ключа среди собственных атрибутов сущности, то рекомендуется ввести вспомогательный суррогатный ключ.
При выборе первичного ключа среди нескольких потенциальных ключей наиболее важными являются следующие факторы:min набор атрибутов (наилучший вариант

Слайд 8Методология логического проектирования реляционной БД
Нужно выполнить следующую последовательность действий:
Исключение элементов,

несовместимых с реляционной моделью данных.
Формирование набора таблиц для логической структуры

реляционной БД.
Проверка полученных таблиц с учетом требований нормализации.
Определение ограничений целостности данных.
Методология логического проектирования реляционной БДНужно выполнить следующую последовательность действий:Исключение элементов, несовместимых с реляционной моделью данных.Формирование набора таблиц

Слайд 91. Исключение элементов, несовместимых с реляционной моделью данных
Концептуальная модель данных

часто содержит конструкции, для которых нет поддержки в реляционных СУБД.
На

этом этапе от таких конструкций нужно избавиться путем их преобразования.
Преобразованию подлежат следующие элементы концептуальной модели данных:
связи типа «многие ко многим»;
сложные связи;
многозначные атрибуты;
связи с атрибутами;
рекурсивные связи.
1. Исключение элементов, несовместимых с реляционной моделью данныхКонцептуальная модель данных часто содержит конструкции, для которых нет поддержки

Слайд 101а) Исключение связи «многие ко многим»
Вместо связи N:М нужно ввести

еще одну промежуточную сущность и две связи 1:М.

1а) Исключение связи «многие ко многим»Вместо связи N:М нужно ввести еще одну промежуточную сущность и две связи

Слайд 111b) Преобразование сложных связей
Исключение сложной связи (степень>2) идет по следующему

сценарию:
в модель добавляется новая сущность;
вводятся бинарные связи типа 1:М для

связи этой сущности с исходными сущностями.
1b) Преобразование сложных связейИсключение сложной связи (степень>2) идет по следующему сценарию:в модель добавляется новая сущность;вводятся бинарные связи

Слайд 12Сложная связь после преобразования:
1с) Исключение многозначных атрибутов
Вместо такого атрибута вводится

новая сущность с соответствующим однозначным атрибутом, который становится первичным ключом.
Между

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

Слайд 13Пример исключения многозначного атрибута
Пусть концептуальная модель содержит сущность ОТДЕЛ с

атрибутом Номер_телефона.
Если некоторые отделы имеют несколько контактных телефонов, то этот

атрибут относится к типу многозначного.
Для исключения из модели такого атрибута вводится дополнительная сущность ТЕЛЕФОН:
Пример исключения многозначного атрибутаПусть концептуальная модель содержит сущность ОТДЕЛ с атрибутом Номер_телефона.Если некоторые отделы имеют несколько контактных

Слайд 142. Формирование набора таблиц для логической структуры реляционной БД
Для каждой

сущности создается таблица и в нее включают все простые атрибуты

этой сущности.
В случае составного атрибута в таблицу включают отдельные простые части этого атрибута.
Связи между разными таблицами реализуются по схеме «первичный ключ/внешний ключ».
Суть этой схемы: из родительской сущности копия первичного ключа передается в дочернюю сущность для его использования в роли внешнего ключа.
2. Формирование набора таблиц для логической структуры реляционной БДДля каждой сущности создается таблица и в нее включают

Слайд 15При реализации бинарных связей типа 1:1 возможны следующие варианты:
Для обеих

сторон участие в связи полное (т.е. связь обязательная)
Такие сущности

целесообразно объединить.

Пример 1:

В этом случае целесообразно паспортные данные включить в таблицу КЛИЕНТЫ.

При реализации бинарных связей типа 1:1 возможны следующие варианты:Для обеих сторон участие в связи полное (т.е. связь

Слайд 16Пример 2:
Для связи между таблицами КЛИЕНТЫ и ПОЖЕЛАНИЯ копия первичного

ключа таблицы КЛИЕНТЫ передается в таблицу ПОЖЕЛАНИЯ и становится там

внешним ключом.

Для одной из сторон участие в связи неполное (т.е. связь необязательная)

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

Пример 2:Для связи между таблицами КЛИЕНТЫ и ПОЖЕЛАНИЯ копия первичного ключа таблицы КЛИЕНТЫ передается в таблицу ПОЖЕЛАНИЯ

Слайд 17Пример 3:
Обе стороны характеризуются неполным участием в связи
Наилучшее решение –

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

Пример 3:Обе стороны характеризуются неполным участием в связиНаилучшее решение – дополнительно ввести промежуточную таблицу для связи конкретных

Обратная связь

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

Email: Нажмите что бы посмотреть 

Что такое TheSlide.ru?

Это сайт презентации, докладов, проектов в PowerPoint. Здесь удобно  хранить и делиться своими презентациями с другими пользователями.


Для правообладателей

Яндекс.Метрика