WHEN ACTORS GO BAD CREATED AT 4 AM

WHEN ACTORS GO BAD CREATED AT 4 AM AFTER WRESTLING WITH RATIONAL ROSE FOR TOO LONG ON A SCHOOL Remark PROJECT.

ст. преподаватель каф. ИВТ Виденин Сергей Александрович ИНФОРМАЦИОННЫЕ СИСТЕМЫ Лекция № 3 Основы проектирования реляционных баз данных

Повторение - мать учения!!! Общая схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования

Класс (class) — абстрактное описание множества однородных объектов, имеющих одинаковые атрибуты, операции и отношения с объектами других классов.

Как класс изображается на диаграмме UML?

А что внутри?

Примеры графического изображения конкретных классов

В языке UML различают конкретные и абстрактные классы Конкретный класс (concrete class) — класс, на основе которого могут быть непосредственно созданы экземпляры или объекты. Абстрактный класс (abstract class) — класс, который не имеет экземпляров или объектов.

Атрибуты класса Атрибут (attribute) — содержательная характеристика класса, описывающая множество значений, которые могут принимать отдельные объекты этого класса. Атрибут класса служит для представления отдельного свойства или признака, который является общим для всех объектов данного класса.

Общий формат записи отдельного атрибута класса <квантор видимости> <имя атрибута> : <тип атрибута> = <исходное значение> {строка-свойство}.

Видимость (visibility) Символ "+" – обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма. Символ "#" – обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса. Символ "-" – обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения. И, наконец, символ "~" - обозначает атрибут с областью видимости типа пакетный (package). Атрибут с этой областью видимости недоступен или невиден для всех классов за пределами пакета, в котором определен класс-владелец данного атрибута.

Операции класса Операция (operation) - это сервис, предоставляемый каждым экземпляром или объектом класса по требованию своих клиентов, в качестве которых могут выступать другие объекты, в том числе и экземпляры данного класса.

Общий формат записи отдельной операции класса <квантор видимости> <имя операции> (список параметров): <выражение типа возвращаемого значения> {строка-свойство}

Отношение обобщения

Отношение агрегации

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

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

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

Определение информационной системы

Системы управления базами данных (СУБД) Cr. UD (Create, Update, Delete) Естественным образом возникает вопрос - а кто или что должно все это поддерживать? Однако после признания концепции БД прошло почти четыре года, прежде чем в 1966 году была создана первая СУБД.

Представление об информационной модели данных

Концепция трех схем

Основные типы моделей данных

Общие принципы классификации СУБД фактографические, которые хранят совокупность фактов интегрированных, возможно, из различных документов; документальные, которые ориентированы на хранение документов; документально-фактографические, которые обладают чертами и тех и других. Так, СУБД CDS/ISIS в первую очередь ориентирована на поддержку работы с документом, который состоит из определенного числа рубрик, проиндексированных по тезаурусу ключевых слов. СУБД ADABAS хорошо подходит для организации фактографических БД, а СУБД ORACLE - для БД смешанного типа.

Модели вычислений Централизованные вычисления: модель вычислений с использованием централизованной хост-ЭВМ; модель с автономными персональными вычислениями; Распределенные вычисления: модель вычислений "файл-сервер"; модель вычислений "клиент-сервер"; модель "вычисление по требованию".

Преимущества и недостатки модели вычислений "клиент-сервер"

Нормализация отношений Первичные ключи отношений должны быть минимальными (требование минимальности первичных ключей). Число отношений базы данных должно по возможности давать наименьшую избыточность данных (требование надежности данных). Число отношений базы данных не должно приводить к потере производительности системы (требование производительности системы). Данные не должны быть противоречивыми, т. е. при выполнении операций включения, удаления и обновления данных их потенциальная противоречивость должна быть сведена к минимуму (требования непротиворечивости данных). Схема отношений базы данных должна быть устойчивой, способной адаптироваться к изменениям при ее расширении дополнительными атрибутами (требование гибкости структуры базы данных). Разброс времени реакции на различные запросы к базе данных не должен быть большим (требование производительности системы). Данные должны правильно отражать состояние предметной области базы данных в каждый конкретный момент времени (требование актуальности данных).

Пример. Аномалии операций над базой данных ПОСТАВКИ (Поставщик, Адрес, Товар, Количество, Стоимость) Обновление. Если Поставщик поставляет несколько видов товара, то значение атрибута Адрес повторяется для каждого кортежа и, следовательно, при изменении адреса поставщика необходимо изменить значение этого атрибута во всех этих кортежах. Иначе будет нарушена целостность данных базы данных. Удаление. Если Поставщик прекращает поставку товаров на некоторое время, то кортежи со всеми его поставками удаляются. При этом происходит потеря реквизитов поставщика - Адреса и Наименования. Вставка. Если договор на поставку уже заключен, а поставка еще не произведена, то невозможно включить в рассматриваемое отношение значения атрибутов Поставщик и Адрес, поскольку нет сведений о поставках (проблема интерпретации нуль-значений).

Подобные аномалии в данных лишь отчасти дают ответ на вопрос, почему логическая структура реляционной БД может быть неудовлетворительной… Некоторые проблемы избыточности данных можно разрешить, заменив, например, исходное отношение ПОСТАВКИ на два новых отношения - отношение ПОСТАВЩИК (Поставщик, Адрес) и отношение ПОСТАВКА (Поставщик, Товар, Количество, Стоимость). Однако в целом остается ряд вопросов, на которые теория реляционных баз данных не дает удовлетворительных ответов: Как найти хорошую замену для плохой схемы отношений? Как определить, является ли выбранная замена выгодной? Как создать схему, обеспечивающую наилучшую производительность?

Контекстная диаграмма процесса проектирования базы данных

Диаграмма декомпозиция процесса проектирования базы данных

Бизнес-модель процесса создания логической модели базы данных

Бизнес-модель процесса нормализации сущности

Бизнес-модель процесса нормализации отношения

Декомпозиция этапа проектирования

Декомпозиция работы по созданию базовой таблицы