Вопрос № 11. Проектирование внутреннего уровня БД
На этом этапе даталогическая модель преобразуется в такую форму, которая позволила бы реализовать БД в среде выбранной СУБД. Проектировщик должен хорошо знать особенности, преимущества и недостатки выбранной СУБД для того, чтобы внутренняя модель обеспечивала высокую эффективность реализуемой БД. Внутренняя модель описывается с помощью языка описания данных – ЯОД (DDL), поддерживаемого выбранной СУБД. Для удаленных СУБД это аналитический язык SQL. Описание всех объектов БД при этом хранится в текстовом файле (словарь данных). Локальные или персональные СУБД поддерживают графический язык описания данных (таблицы Access). Проектирование внутреннего уровня рекомендуется начать с технического описания таблиц. При этом наглядно показаны типы опциональности и ограничения атрибутов. Эти описания достаточно сильно различаются в зависимости от того, какая СУБД выбрана.
ЭТАПЫ Проектирования внутреннего уровня:
1) Проектирование структур таблиц. Здесь задается уникальное имя таблицы, имена полей таблицы, типы и размеры полей, их опциональность, ограничения накладываемые на поля.
2) Реализация ограничений ссылочной целостности. Выбирается 1 из стратегий обеспечения ссылочной целостности, поддерживаемая выбранной СУБД. Если связь непереносима, то при обновлении следует выбрать стратегию RESTRICT. Если связь обязательна, то мы не можем выбрать стратегию SET NULL, т.к. обязательным является значение внешнего ключа. Ссылочная целостность обеспечивается как декларативным, так и процедурным путем.
3) Проектирование индексов, индексных файлов. Индексы используются для упорядочения записей и файлов в целях ускорения доступа к ним. В отличии от отсортированных файлов, индексные имеют небольшой объем, т.е. содержат только номера записей исходного файла в упорядоченном виде. Индекс можно строить по значениям 1 поля (простой индекс) или нескольких полей (составной).
Рекомендуется создавать индексы для полей, по которым будет часто осуществляться поиск и по которым при реализации запроса будет часто проводиться операция соединения таблиц. Не рекомендуется создавать индексы для длинных текстовых файлов, для полей содержащих много пустых значений, для полей с небольшим числом инвариантных значений.
4) Реализация сложных ограничений семантической целостности. Такие ограничения реализуются процедурным путем с помощью объектов трикеры и хранимые процедуры.
5) Создание БД. Разработанная внутренняя модель используется для создания физической БД в среде выбранной СУБД. Ранние СУБД предлагали проектировщику выбрать из нескольких уровней организации наиболее эффективную. Современные СУБД этого выбора не дают. Это либо является коммерческой тайной, либо СУБД реализует только 1 физическая модель. Современные СУБД используют странично-сегментную физическую модель организации данных. Ранние СУБД использовали файловые модели, при чем файлы могли быть последовательные, прямые, индексно-последовательные, кэшированные. Если внутренняя модель представлена с помощью языка SQL, БД создается путем выполнения этих операций. При создании БД следует выделить на диске достаточный участок с учетом расширения БД. Для многопользовательских БД администратор определяет круг пользователей и права их доступа.
На этом этапе даталогическая модель преобразуется в такую форму, которая позволила бы реализовать БД в среде выбранной СУБД. Проектировщик должен хорошо знать особенности, преимущества и недостатки выбранной СУБД для того, чтобы внутренняя модель обеспечивала высокую эффективность реализуемой БД. Внутренняя модель описывается с помощью языка описания данных – ЯОД (DDL), поддерживаемого выбранной СУБД. Для удаленных СУБД это аналитический язык SQL. Описание всех объектов БД при этом хранится в текстовом файле (словарь данных). Локальные или персональные СУБД поддерживают графический язык описания данных (таблицы Access). Проектирование внутреннего уровня рекомендуется начать с технического описания таблиц. При этом наглядно показаны типы опциональности и ограничения атрибутов. Эти описания достаточно сильно различаются в зависимости от того, какая СУБД выбрана.
ЭТАПЫ Проектирования внутреннего уровня:
1) Проектирование структур таблиц. Здесь задается уникальное имя таблицы, имена полей таблицы, типы и размеры полей, их опциональность, ограничения накладываемые на поля.
2) Реализация ограничений ссылочной целостности. Выбирается 1 из стратегий обеспечения ссылочной целостности, поддерживаемая выбранной СУБД. Если связь непереносима, то при обновлении следует выбрать стратегию RESTRICT. Если связь обязательна, то мы не можем выбрать стратегию SET NULL, т.к. обязательным является значение внешнего ключа. Ссылочная целостность обеспечивается как декларативным, так и процедурным путем.
3) Проектирование индексов, индексных файлов. Индексы используются для упорядочения записей и файлов в целях ускорения доступа к ним. В отличии от отсортированных файлов, индексные имеют небольшой объем, т.е. содержат только номера записей исходного файла в упорядоченном виде. Индекс можно строить по значениям 1 поля (простой индекс) или нескольких полей (составной).
Рекомендуется создавать индексы для полей, по которым будет часто осуществляться поиск и по которым при реализации запроса будет часто проводиться операция соединения таблиц. Не рекомендуется создавать индексы для длинных текстовых файлов, для полей содержащих много пустых значений, для полей с небольшим числом инвариантных значений.
4) Реализация сложных ограничений семантической целостности. Такие ограничения реализуются процедурным путем с помощью объектов трикеры и хранимые процедуры.
5) Создание БД. Разработанная внутренняя модель используется для создания физической БД в среде выбранной СУБД. Ранние СУБД предлагали проектировщику выбрать из нескольких уровней организации наиболее эффективную. Современные СУБД этого выбора не дают. Это либо является коммерческой тайной, либо СУБД реализует только 1 физическая модель. Современные СУБД используют странично-сегментную физическую модель организации данных. Ранние СУБД использовали файловые модели, при чем файлы могли быть последовательные, прямые, индексно-последовательные, кэшированные. Если внутренняя модель представлена с помощью языка SQL, БД создается путем выполнения этих операций. При создании БД следует выделить на диске достаточный участок с учетом расширения БД. Для многопользовательских БД администратор определяет круг пользователей и права их доступа.