- •Система управления базами данных (субд).
- •Компоненты среды субд.
- •Распределение обязанностей в системах с бд.
- •Преимущества субд.
- •Недостатки субд.
- •Из истории развития субд.
- •Среда базы данных.
- •Трехуровневая архитектура ansi-sparc.
- •Схемы, отображения и экземпляры.
- •Модели данных и концептуальное моделирование.
- •Основные функции, сервисы и службы субд.
- •Компоненты типовых субд.
- •Компоненты типового контроллера базы данных.
Преимущества субд.
“Есть только одно благо – знание и только одно зло – невежество.”
СОКРАТ, ок.470-399гг. до н.э.

Контроль за избыточностью данныхпо сравнению с файловыми системами.
Непротиворечивость данных, которая обеспечивается контролем как состояния для каждого элемента данных, так и для его рабочих копий.
Совместное использование данныхбольшим количеством пользователей.
Поддержка целостности данных, означающая корректность и недопускающая получения логически противоречивых результатов запросов к БД для пользователей.
Повышенная безопасностьи конфиденциальность по правам доступа пользователей.
Применение стандартов, что позволяет облечать взаимодействие организаций и людей.
Рост эффективности при расширении системы, т.к. объединяются различные ресурсы.
Управление компромиссами при конфликтахтребований различных клиентов, т.к. общие информационные ресурсы находятся под единым контролем АБД.
Повышение доступности данных и их готовностик работе обеспечивает более высокое качество обслуживания клиентов БД, часто даже без помощи программистов.
Рост производительности обработки данныхза счет использования программных инструментов высокого уровня, не требующих рутинного программирования запросов.
Упрошение сопровождения сложных системза счет разделения по данным и в конечном итоге создание систем “независимых от данных”.
Улучшение управления параллельностьюза счет четкой организации и использования готового механизма поддержания транзакций в запросах к общей БД.
Надежностьза счет служб резервного копирования и восстановления данных.
Недостатки субд.
“Женишься ты или нет – все равно раскаешься.”
СОКРАТ, ок.470-399гг. до н.э.

Рост количественной сложности.Кажущаяся элегантная легкость с которой происходит подключение новых пользователей и ввод новых сущностей в БД приводит к нарастанию размерности предметных областей, хранящихся в БД. Это должны понимать все, иначе со временем накопление количественной сложности приводит к изменению качественных характеристи системы.
Рост качественной сложности. Обеспечение необходимой функциональности СУБД, неизбежно приводит к повышению уровня качественной сложности. Логика функционирования становится все более запутанной и управление системой требует высоко квалифицированных специалистов, которых всегда мало на рынке труда.
Высокая стоимость СУБД.Относительно низкая стоимость персональных СУБД объясняется их низкой функциональностью. Как инструмент СУБД предназначена для овладения сложностью организации социально-экономических систем и тут возникают очень сложные корпоративные задачи, решения для которых оцениваются очень дорого. При этом надо различать: стоимость СУБД как инструмента и стоимость новой коллективной культуры его использования, а за отдельную плату – адаптацию культуры использования СУБД её к конкретной проблемной ситуации.
Затраты на аппаратное обеспечение. Новые функциональные требования часто наиболее просто удовлетворить решить приобретая новое программно-совместимое и более производительное аппаратное обеспечение. Не стоит обольщаться, такой момент объзательно наступит гораздораньше, чем его ожидают.
Затраты на преобразование.По мере работы происходит накопление информации, стоимость которой может оказаться выше всех прямых затрат на СУБД, например как коллективной истории бизнеса и его “наследия”. Очередная информационная революция может потребовать преобразования существующей СУБД, но что делать с накопленными архивами? Их перенос может потребовать слишком много времени и средств, поэтому часто оставляют для обслуживания специальных запросов устаревшую, традиционную систему СУБД. Прогресс не может быть слишком быстрым.
Проблема общей и специальной производительности. Идея и реализация СУБД как инструмента массового обслуживания – выдающееся достижение информационных технологий. Но на ряду с общими есть и специальные потребности. Для некоторых из них файловые системы оказались значительно более эффективными. Ситуация напоминает экологическую систему, где в единстве сосуществуют разные биологические виды. Поэтому в реальных системах использование СУБД должно предусматнивать как общий, так и специальные варианты.
Серьёзные последствия при выходе из строя. Централизация ресурсов повышает уязвимость системы. Поскольку работа всех пользователей и приложений зависит от готовности к работе СУБД, выход её из строя может привести к полному прекращению её работы. Поэтому важно иметь сценарий парирования нештатных режимов работы СУБД в виде административных, организационных и методических мероприятий (как на случай пожара). При этом разумно иметь варианты автономного режима работы для приложений. В наиболее критических случаях надо использовать более устойчивую и живучую архитектуру с распределёнными БД.
Проблема ответственности. Любые бизнес-правила и традиции вырабатывались в определённых условиях функционирования организации. Внедрение СУБД приводит к достаточно жесткой формализации деятельности персонала и клиентов. Но нет правил без исключений, поэтому необходимо предусматривать в реальных ситуациях принятия решений контроль “здравого смысла”, за который может нести отвественность только человек. По мере усложнения проблемных ситуаций сложность такого контроля часто превышает человеческие возможности. При выборе СУБД, создании БД и проектировании системы надо предусматривать эту “ловушку” в двух аспектах её проявления: попыток перекладывания отвественности целиком на бизнес-правила (т.е. на компьютер) и выявление “непосильных” решений.
