- •В чем суть теории нормализации реляционной модели данных.
- •Почему схемы реляционных баз данных могут быть плохими. Примеры
- •Сложные домены и первая нормальная форма. Примеры
- •Функциональная зависимость. Основные определения. Примеры
- •Ключи отношения с точки зрения функциональной зависимости. Примеры
- •Свойства функциональных зависимостей. Примеры.
- •Логическое следование функциональных зависимостей. Примеры
- •Замыкание, полнота, эквивалентность и минимальное покрытие функциональных зависимостей. Примеры
- •Неполная (частичная) функциональная зависимость и вторая нормальная форма. Примеры
- •Транзитивная зависимость и третья нормальная форма. Примеры.
- •Усиленная третья нормальная форма и нормальная форма Бойса-Кодда. Примеры
- •Четвертая нормальная форма. Примеры.
- •Связь зависимостей по соединению и многозначных зависимостей.
- •Формальная постановка задачи проектирования реляционной схемы
- •Декомпозиция схемы реляционного отношения
- •Эквивалентность схем отношений по зависимостям
- •Эквивалентность схем отношений по данням
- •Эквивалентность нормальных форм.
- •Этапы жизненного цикла разработки бд
- •Методология проектирования бд
- •Этап определения стратегии автоматизации по
- •Этап системного анализа по
- •Этап концептуального моделирования по
- •Этап логического и физического проектирования
- •28) Язык er-моделирования. Сущности. Примеры
- •29) Язык er-моделирования. Атрибуты. Примеры
- •30) Язык er-моделирования. Связи. Примеры
- •31) Язык er-моделирования. Допустимые и недопустимые связи. Примеры.
- •32) Язык er-моделирования. Подтипы и супертипы. Примеры.
- •33) Язык er-моделирования. Разрешение связей многие-ко-многим. Примеры
- •39) Язык er-моделирования. Представление уникальных идентификаторов столбцами-заменителями
Этап концептуального моделирования по
Этап концептуального моделирования – это построение строго описания ПО в терминах некоторого формального языка
Роли концептуальной модели:
Единая основа однозначного понимания ПО всеми заинтересованными лицами
Включает только концептуально релевантные аспекты ПО
Средство определения допустимой эволюции информационной модели ПО
Ключевые результаты этапа концептуального моделирования
Формальное описание информационной модели ПО.
Подробное и строгое описание хранилищ данных.
Детальное описание потоков данных.
Детальное описание иерархии решаемых задач с детальной спецификацией всех задач.
Детальное описание действующих в предметной области правил и ограничений
Этап логического и физического проектирования
Этап проектирования - это поиск и определение наилучше- го способа реализации и удовлетворения требований, разработанных на этапах анализа, и концептуального моделирования с обеспечением согласованного уровня сервиса в условиях заданной технико-технологической среды и в соответствии с ранее принятыми решениями об уровне автоматизации
Логическое проектирование – это разработка логической структуры системы баз данных без привязки к конкретной СУБД, структурам хранения, методам доступа и т.д.
Физическое проектирование – это проект системы базы данных на конкретной СУБД.
Ключевые результаты этапа проектирования
Архитектура системы
Схемы системных модулей
Логическая и физическая схемы БД
Детальные объемно-частотные характеристики
Программные спецификации
Спецификации неавтоматизированных процедур
Согласованная стратегия внедрения, включающая в себя планы приема и сдачи системы, организационной подготовки, мероприятий по сбору данных, перехода на новую систему и установки оборудования
План испытаний системы
Черновой вариант эксплуатационной документации
Уточненный план разработки системы
28) Язык er-моделирования. Сущности. Примеры
Язык ER-моделирования - это язык определения информационной модели ПО. Базируется на концепции, согласно которой информационная модель ПО может быть описана в терминах: сущность, атрибут, связь. Используется на этапе анализа и прежде всего – концептуального моделирования. Язык является существенно графическим.
Сущность - это реальный или воображаемый объект, информация о котором подлежит сбору или хранению.
Графически сущность представляется поименованным прямоугольником с закругленными углами
Имя сущности дается в единственном числе заглавными буквами.
Любой объект может быть представлен только одной сущностью. Значит сущности всегда являются взаимоисключающими.
Каждая сущность должна быть уникально идентифицируема. Это означает, что должен существовать способ независимой идентификации каждого экземпляра сущности, позволяющий отличать его от всех других экземпляров данного типа сущности.
Правило – атрибут описывает одну сущность
Атрибут должен описывать ту сущность, к которой он отнесен!
Атрибутом какой сущности является "номер места":- билета, купона, посадочного талона, воздушного судна?
Правило – атрибуты не должны повторяться (1NF)
Сущность может обладать лишь одним значением атрибута. Если же многозначность атрибута играет существенна, надо определить новую сущность, в которую войдут эти значения, и соединить ее с исходной сущностью связью многие-к-одному
Правило – сущность обладает уникальной идентификацией
Каждая сущность должна однозначно идентифицироваться посредством некоторой комбинации атрибутов и/или связей