Разделы презентаций
- Разное
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Lecture7.ppt
Содержание
- 1. Lecture7.ppt
- 2. Важно, что такая модель никак не зависит
- 3. 2. Логическое проектирование БД – это процесс
- 4. Важную роль логическая модель данных играет и
- 5. В случае реляционной БД это означает:выбор конкретной
- 6. Методология концептуального проектирования БДОпределение типов (классов) сущностейОпределение
- 7. При выборе первичного ключа среди нескольких потенциальных
- 8. Методология логического проектирования реляционной БДНужно выполнить следующую
- 9. 1. Исключение элементов, несовместимых с реляционной моделью
- 10. 1а) Исключение связи «многие ко многим»Вместо связи
- 11. 1b) Преобразование сложных связейИсключение сложной связи (степень>2)
- 12. Сложная связь после преобразования:1с) Исключение многозначных атрибутовВместо
- 13. Пример исключения многозначного атрибутаПусть концептуальная модель содержит
- 14. 2. Формирование набора таблиц для логической структуры
- 15. При реализации бинарных связей типа 1:1 возможны
- 16. Пример 2:Для связи между таблицами КЛИЕНТЫ и
- 17. Пример 3:Обе стороны характеризуются неполным участием в
- 18. Скачать презентанцию
Важно, что такая модель никак не зависит от любых аспектов ее физической реализации:тип СУБД и вычислительной платформы;набор прикладных программ;средства программирования приложений и др.Концептуальная модель данных создается на основе информации, записанной в
Слайды и текст этой презентации
Слайд 1Этапы проектирования БД
Процесс проектирования БД состоит их трех основных этапов:
концептуальное
проектирование;
высокоуровневой семантической модели для данных, которые присутствуют в определенной предметной области.
Слайд 2Важно, что такая модель никак не зависит от любых аспектов
ее физической реализации:
тип СУБД и вычислительной платформы;
набор прикладных программ;
средства программирования
приложений и др.Концептуальная модель данных создается на основе информации, записанной в требованиях пользователей.
Дополнительно проводится специальный опрос (анкетирование) пользователей.
В процессе разработки этой модели она постоянно обсуждается с пользователями для достижения полного согласия.
Слайд 32. Логическое проектирование БД – это процесс создания информационной модели
на основе выбранной модели структурной организации данных при их хранении
и обработке.Это делается без выбора конкретной СУБД и без учета остальных аспектов физической реализации БД.
Логическая модель данных создается путем преобразования концептуальной модели с учетом особенностей выбранной модели организации данных.
Слайд 4Важную роль логическая модель данных играет и при эксплуатации (сопровождении)
уже готовой БД.
Эта модель, если ее постоянно поддерживать в актуальном
состоянии, позволяет точно и наглядно представить любые изменения в структуре БД, а также оценить их влияние на прикладное ПО.3. Физическое проектирование – это процесс принятия решений по реализации проекта разрабатываемой БД.
Слайд 5В случае реляционной БД это означает:
выбор конкретной (целевой) СУБД;
построение процедуры
создания таблиц на жестком диске;
определение методов доступа к данным, чтобы
обеспечить высокую производительность СУБД:выбор необходимой файловой структуры (т.е. типов файлов для хранения данных);
оценка целесообразности использования индексных файлов;
планирование средств информационной безопасности и защиты данных.
Слайд 6Методология концептуального проектирования БД
Определение типов (классов) сущностей
Определение атрибутов для сущностей
Определение
доменов для атрибутов
Определение потенциальных и первичных ключей
Определение типов связей между
сущностямиПостроение ER-диаграммы
Слайд 7При выборе первичного ключа среди нескольких потенциальных ключей наиболее важными
являются следующие факторы:
min набор атрибутов (наилучший вариант – простой ключ
целого типа);значения min длины;
высокая стабильность (т.е. min вероятность изменения значений);
простота работы для пользователя.
Если нет возможности сделать удачный выбор первичного ключа среди собственных атрибутов сущности, то рекомендуется ввести вспомогательный суррогатный ключ.
Слайд 8Методология логического проектирования реляционной БД
Нужно выполнить следующую последовательность действий:
Исключение элементов,
несовместимых с реляционной моделью данных.
Формирование набора таблиц для логической структуры
реляционной БД.Проверка полученных таблиц с учетом требований нормализации.
Определение ограничений целостности данных.
Слайд 91. Исключение элементов, несовместимых с реляционной моделью данных
Концептуальная модель данных
часто содержит конструкции, для которых нет поддержки в реляционных СУБД.
На
этом этапе от таких конструкций нужно избавиться путем их преобразования.Преобразованию подлежат следующие элементы концептуальной модели данных:
связи типа «многие ко многим»;
сложные связи;
многозначные атрибуты;
связи с атрибутами;
рекурсивные связи.
Слайд 101а) Исключение связи «многие ко многим»
Вместо связи N:М нужно ввести
еще одну промежуточную сущность и две связи 1:М.
Слайд 111b) Преобразование сложных связей
Исключение сложной связи (степень>2) идет по следующему
сценарию:
в модель добавляется новая сущность;
вводятся бинарные связи типа 1:М для
связи этой сущности с исходными сущностями.
Слайд 12Сложная связь после преобразования:
1с) Исключение многозначных атрибутов
Вместо такого атрибута вводится
новая сущность с соответствующим однозначным атрибутом, который становится первичным ключом.
Между
новой и исходной сущностями организуется связь типа 1:М.
Слайд 13Пример исключения многозначного атрибута
Пусть концептуальная модель содержит сущность ОТДЕЛ с
атрибутом Номер_телефона.
Если некоторые отделы имеют несколько контактных телефонов, то этот
атрибут относится к типу многозначного.Для исключения из модели такого атрибута вводится дополнительная сущность ТЕЛЕФОН:
Слайд 142. Формирование набора таблиц для логической структуры реляционной БД
Для каждой
сущности создается таблица и в нее включают все простые атрибуты
этой сущности.В случае составного атрибута в таблицу включают отдельные простые части этого атрибута.
Связи между разными таблицами реализуются по схеме «первичный ключ/внешний ключ».
Суть этой схемы: из родительской сущности копия первичного ключа передается в дочернюю сущность для его использования в роли внешнего ключа.
Слайд 15При реализации бинарных связей типа 1:1 возможны следующие варианты:
Для обеих
сторон участие в связи полное (т.е. связь обязательная)
Такие сущности
целесообразно объединить.Пример 1:
В этом случае целесообразно паспортные данные включить в таблицу КЛИЕНТЫ.
Слайд 16Пример 2:
Для связи между таблицами КЛИЕНТЫ и ПОЖЕЛАНИЯ копия первичного
ключа таблицы КЛИЕНТЫ передается в таблицу ПОЖЕЛАНИЯ и становится там
внешним ключом.Для одной из сторон участие в связи неполное (т.е. связь необязательная)
Сущность, для которой имеет место неполное участие в связи, объявляется родительской.
После этого можно применять схему «первичный ключ/внешний ключ».
Слайд 17Пример 3:
Обе стороны характеризуются неполным участием в связи
Наилучшее решение –
дополнительно ввести промежуточную таблицу для связи конкретных экземпляров исходных сущностей
