Ответы к экзамену по БД, страница 2

Стандартизация (ANSI/SPARC)осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволилоуспешно решить задачу взаимодействия различных реляционных СУБД с помощью языка SQL.4. Этапы проектирования баз данных и их характеристика.• Этап формулирования и анализа требованийНа этапе формулирования и анализа требований устанавливаются цели организации, определяютсятребования к БД. Они состоят из общих требований и специфических требований. Для формированияспецифических требований обычно используется методика интервьюирования персонала различных уровнейуправления. Все требования документируются в форме, доступной конечному пользователю ипроектировщику БД.• Этап концептуального проектированияЭтап концептуального проектирования заключается в описании и синтезе информационных требованийпользователей в первоначальный проект БД.

Исходными данными могут быть совокупность документовпользователя при классическом подходе или алгоритмы приложений (алгоритмы бизнеса) при современномподходе. По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базыданных. Часто она представляется в виде модели «сущность-связь».• Этап логического проектированияВ процессе логического проектирования высокоуровневое представление данных преобразуется в структуруиспользуемой СУБД.

Основной целью этапа является устранение избыточности данных с использованиемспециальных правил нормализации. Цель нормализации - минимизировать повторения данных и возможныеструктурные изменения БД при процедурах обновления. Это достигается разделением (декомпозицией)одной таблицы в две или несколько с последующим использованием при запросах операции навигации.Заметим, что навигационный поиск снижает быстродействие БД, т.е. увеличивает время отклика на запрос.На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ.На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительныйанализ моделей.• Этап физического проектированияНа этапе физического проектирования решаются вопросы, связанные с производительностью системы,определяются структуры хранения данных и методы доступа.Различие уровней представления данных на каждом этапе проектирования реляционной базыданных:КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ — Представление аналитика (используется инфологическая модель «сущностьсвязь»)• сущности• атрибуты• связиЛОГИЧЕСКИЙ УРОВЕНЬ — Представление программиста• записи• элементы данных• связи между записямиФИЗИЧЕСКИЙ УРОВЕНЬ — Представление администратора• группирование данных• индексы• методы доступаСредства проектирования и оценочные критерии используются на всех стадиях разработки.

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

Case-средства для проектирования БД. Общая характеристика. Примеры.Можно вписать что-нито про ERWIN )Подавляющее большинство подобных систем, представленных на рынке, обеспечивает автоматизированноепреобразование диаграммных концептуальных схем баз данных, представленных в той илииной семантической модели данных, в реляционные схемы, специфицированные чаще всего на языке SQL. Неавтоматические потому, что в типичной схеме SQL-ориентированной БД могут содержаться определениямногих объектов (ограничений целостности общего вида, триггеров и хранимых процедур и т. д.), которыеневозможно сгенерировать автоматически на основе концептуальной схемы.

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

Важнейшими (базовыми) принципами являются деление (декомпозиция) ипоследующее иерархическое упорядочение.Они дополняются следующими принципами.• Принцип абстрагирования от несущественных деталей (с их «упрятыванием») с контролем наприсутствие лишних элементов.• Принцип формализации.• Принцип концептуальной общности (структурный анализ - структурное программирование структурное тестирование). Отсюда методология структурного анализа - метод исследования отобщего обзора через детализацию к иерархической структуре со все большим числом уровней.• Принцип непротиворечивости - обоснование и согласованность элементов.• Принцип логической и физической независимости данных.• Принцип непосредственного доступа (без программирования) конечного пользователя.Эта технология положена в основу реализации программных CASE-средств.Пакет CASE-средств обычно содержит 4 основных компонента.• Средства централизованного хранения информации о всем проекте (своеобразная база данныхпроекта).• Средства ввода данных для хранения.• Средства анализа, проектирования и разработки.• Средства вывода.Для CASE-технологии (сокращенно - CASE) характерны четыре основных типа графических диаграмм:• функциональное проектирование (DFD);• моделирование данных (ERD);• моделирование поведения (STD);• структурные диаграммы (карты) - отношения между модулями и внутри- модульная структура.Как правило, CASE-средства, автоматизирующие преобразование концептуальной схемы БД вреляционную, производят реляционную схему базы данных в третьей нормальной форме.

Нормализацияболее высокого уровня усложняет программную реализацию и редко требуется на практике.ПримерыПроектирование БД существенно упрощается при применении ERWin (фирма Logic Works), Designer/2000(Oracle), позволяющих проводить логическое моделирование данных, автоматическое преобразованиеданных в ЗНФ.6. Модели данных в БД. Основные понятия и определения.Модель данных — это абстрактное, самодостаточное, логическое определение объектов, операторов ипрочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которойвзаимодействует пользователь. Упомянутые объекты позволяют моделировать структуру данных, аоператоры — поведение данных.

(по Дейту)Используя это определение, можно эффективно разделить понятия модели данных и еереализации.Реализация (implementation) заданной модели данных — это физическое воплощение на реальной машинекомпонентов абстрактной машины, которые в совокупности составляют эту модель.Короче говоря, модель — это то, о чем пользователи должны знать, а реализация - этото, чего пользователи не должны знать.Одним из первых специалистов, который достаточно формально определил это понятие, был Э. Кодд. Онопределил модель данных как комбинацию трех компонентов:• Коллекции типов объектов данных, образующих базовые строительные блоки для любой базыданных, соответствующей модели• Коллекции общих правил целостности, ограничивающих набор экземпляров тех типов объектов,которые законным образом могут появиться в любой такой базе данных• Коллекции операций, применимых к таким экземплярам объектов для выборки и других целей.(по Кодду)Каждая БД и СУБД строится на основе некоторой явной или неявной модели данных.

Все СУБД, построенныена одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБДявляется реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД —иерархическая модель данных и т.д.Классификация моделей данныхМодели данныхИнфологическиемоделиДиаграммыБахманаОриенированные наформатдокументаДаталогическиемоделиМодельсущностьсвязь (ER)ДескрипторныемоделиДокументальныемоделиТезаурусные моделиИерархическаяФактографическиемоделиТеоретикографовыеСетеваяФизическиемоделиОснованные нафайловыхструктурахТеоретикомножественныеРеляционнаяОснованныенастраничносегментнойорганизацииОбъектноориентированныеБинарныхассоциаций7.Характеристика компонент моделей данных (реляционной,иерархической, сетевой).