Лекция 2. Проектирование баз данных и хранилищ данных

Классификация предприятий по категориям

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

- Элит-класс;

- Престиж-класс;

– I класс;

– II класс;

– III класс;

– Без класса.

Показатели для отнесения предприятий к определенному классу приведены в таблице. В то же время любая станция технического обслуживания, незави­симо от класса, должна иметь удобные подъездные пути с необходимыми дорожными знаками и указателями, площадку с твердым покрытием для стоянки авто­мобилей клиентов и сотрудников, эстетичный внешний вид, вывеску с указани­ем «СТО» и/или ее названием, место приемки клиентов. Каждая СТО должна отвечать требованиям «Руководящего документа по сертификлции услуг» (при­каз Государственного комитета по стандартизации, метрологии и сертификации Украины № 520 от 28.08.1997 г.):

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

– иметь технологическое оборудование и инструмент, предусмотренный технологической документацией;

– иметь средства измерения и испытательное оборудование, предусмот­ренное нормативной и технической документацией;

– иметь персонал, выполняющий работу и контролирующий ее качество, обладающий достаточной квалификацией, знаниями и опытом;

– использовать для ремонта и обслуживания запасные части и материалы, качество и безопасность которых подтверждены соответствующим сертификатом;

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

Таблица 2.2 – Требования к станциям определенной категории

Жизненный цикл баз данных - это совокупность этапов, от создания БД до окончания ее использования.

№	Этапы	Содержание этапа
	Планирование разработки БД	Определение объема работ, ресурсов и стоимости проекта
	Определение требований к системе	Определить диапазон действия БД, состав пользователей, области применения. Разработка стандартов: как сбор данных, формат
	Сбор и анализ требований пользователей	Определить информационные потребности пользователей (их опрос, документооборот)
	Проектирование БД:	Концептуальное проектирование	Создать концептуальную схему данных
Логическое проектирование	Создать логическую модель данных
Физическое проектирование	Действия специфичны для разных моделей данных
	Разработка приложений	Проектирование транзакций	Определить: 1. Данные используемые транзакцией, 2. Функциональные характеристики транзакций, 3. Выходные данные, формируемые транзакцией, степень важности и интенсивности использования транзакции.
Проектирование пользовательского интерфейса
	Реализация	Создаются схемы и пустые файлы базы данных
	Загрузка данных	Созданные пустые файлы заполняются данными
	Тестирование	Выявление ошибок, неучтенных информационных потребностей. Активно привлекаются пользователи.
	Эксплуатация и сопровождение	Анализ функционирования	Контроль производительности системы, разрешение проблем, созданием дополнительных компонент
Адаптация, модернизация, поддержка	Отражение организационных изменений в БД

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

Cсуществует 2 подхода к проектированию БД:

1) классический (80-е гг) - анализ и автоматизация делопроизводства.

2) современный (с 90х гг) – анализ стандартных бизнес-процессов и необходимых данных.

Совокупность процедур проектирования БД можно разделить на четыре этапа.

1. Этап формулирования и анализа требований - устанавливаются цели организации, определяются требования к БД. Они состоят из общих требований, и специфических тре­бований. Для формирования специфических требований обычно используется интервьюирование персонала различных уров­ней управления. Все требования документируются в форме, доступ­ной конечному пользователю и проектировщику БД.

2. Этап концептуального проектирования заключается в описании и синтезе информационных требований пользователей в первоначаль­ный проект БД. Исходными данными могут быть совокупность до­кументов пользователя при классическом подходе или алгоритмы приложений (алгоритмы бизнеса) при современном под­ходе. Результатом этого этапа является высокоуровневое представ­ление (в виде системы таблиц БД) информационных требований пользователей на основе различных подходов. Сначала выбирается модель данных БД и СУБД. Затем с помощью ЯОД создается структура БД, которая затем заполняется данными с помощью команд ЯМД (языка манипуляции данными), систем меню, экранных форм или в режиме просмотра таблиц БД. Здесь же обес­печивается защита и целостность дан­ных.

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

Процедура управления БД наиболее проста в однопользовательском режиме. В много­пользовательском режиме и в распределенных БД процедура сильно усложняется. При одновременном доступе нескольких пользовате­лей без принятия специальных мер возможно нарушение целостно­сти. Для устранения этого явления используют систему транзакций и режим блокировки таблиц или отдельных записей.

Рис. Этапы проектирования операционных БД

4. Этап физического проектирования решаются вопросы, свя­занные с производительностью системы, определяются структуры хранения данных и методы доступа.

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

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

Процесс проектирования является длительным и трудоемким и обычно продолжается несколько месяцев.

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

Выделяют три типа связей «один к одному» (1:1 студент<->адрес), «один ко многим» (1:М группа <->>студент), «многие ко многим» (M:N, студент <<->>преподаватель).

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

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

Избыточность данных в БД - нежелательное явление, т.к. ведет к увеличению объема памяти, необходимого для хра­нения БД. Избыточность вызывается дублированием данных. Не все случаи дублирования данных нужно исклю­чать. Если попробовать реализовать подобную ситуацию, то вместо единой БД со связанными между собой объектами получим разрозненные отношения. Поэтому избыточность полностью устранять не требуется, нужно лишь ее минимизировать так, чтобы были устранены некоторые ее виды, а осталась только доля избыточности, необходимая для удержания БД как единого целого.

Вот характерный пример отношения, содержащего нежелатель­ную избыточность:

В данном отношении с первичным ключом Ном_зач_кн в каждом кортеже о каждом студенте из одной и той же группы повторяются сведения о коде группы, старосте и кураторе. Помимо того, что для их хранения потребуют­ся дополнительные ресурсы памяти, при дублировании информации очень несложно допустить ошибку при вводе значений атрибутов, в результате чего база данных перейдет в несогласованное состояние.

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