Экзамен / 56 57 74

56. Проектирование БД средствами ERWin

Case ERwin представляет собой средство концептуального моделирования БД, реализует функции проектирования схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Ingres, Sybase, DB/2, Microsoft SQL Server и др.) и реинжиниринг существующей БД. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств. Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.

Семейство продуктов ERWin предназначено для моделирования и создания БД произвольной сложности. В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов: SQL-серверов (Oracle, Sybase, MS SQL Server, DB2, Ingress и др.) и “настольных” СУБД dBASE, FoxPro, MS Access и др.). ERwin Data Modeling Suite предоставляет расширенную поддержку СУБД Teradata, SQL Server 2008 и DB2 z/OS v.9, возможности обмена метаданными с инструментами управления данными Oracle Business Intelligence.

Информационная модель представляется в виде диаграмм “сущность-связь”, отражающих основные объекты предметной области и связи между ними. Дополнительно определяются атрибуты сущностей, характеристики связей, индексы и бизнес-правила, описывающие ограничения и закономерности предметной области. После создания ER-диаграммы пакет автоматически генерирует SQL-код для создания таблиц, индексов и других объектов БД. По заданным бизнес-правилам формируются стандартные триггеры БД для поддержки целостности данных, для сложных бизнес-правил можно создавать собственные триггеры, используя библиотеку шаблонов.

Дальше пример из л.р. 4.

57. Место СУБД в системе информационного обслуживания управленческой деятельности; эволюция развития СУБД; функциональная структура СУБД.

Место СУБД в системе информационного обслуживания управленческой деятельности - СППР же!

Эволюция развития СУБД:

1. СУБД первого поколения(иерархическая –> сетевая модель данных). Поголовно коммерческие и использовались для работы на мейнфремах. Недостатки – сложно писать запросы, нет четких стандартов. Пример - IMS (Information Management System), разработанная в 60х.

2.СУБД второго поколения (реляционная модель данных), разработан SQL – стандартный ЯМД для всех реляционных СУБД. Используются и на ПК, и на мейнфремах. Недостатки – ограниченные возможности моделирования. Пример – современные СУБД Access, Oracle и т.д.

3. СУБД третьего поколения(обьектно-ориентированная и обьектно-реляционная модели данных). Разрабатываются для упрощения приложений баз данных.

Не стоит думать, что в наше время не используются СУБД первого поколения – сейчас такие системы известны как NoSQL СУБД.

Функциональная структура СУБД:

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

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

Дополнительные компоненты СУБД - это служебные программы, играющие важную роль в процессе работы с БД и предназначенные для: создания (загрузки) БД; копирования содержимого БД с целью восстановления в случаях аварийных ситуаций; реорганизации БД, чтобы получить более эффективный ее вариант; печати как частей, так и всей БД; сбора и получения статистических данных об использовании записей, файлов, путей доступа и т.п.; восстановления содержимого БД, начиная с некоторой контрольной точки, при возникновении аварийных ситуаций.

74. Как можно обеспечить надежность хранения данных - Многоуровневая организация данных

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