Общие замечания. Ниже приводятся примеры проектирования баз данных

Ниже приводятся примеры проектирования баз данных. В изложении примеров используются следующие допущения:

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

2. В примерах реализованы этапы только инфологического и даталогического проектирования.

3. Разработка информационных моделей осуществляется в соответствии с методологией IDEF1X.

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

5. Для обозначения мощности связи, определенной как «нуль, один или более» и не требующей специальных пометок на диаграмме, в таблицах использован символ B.

6. При описании атрибутов сначала должны быть определены атрибуты родительских множеств сущностей, затем дочерних.

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

8. В результате проектирования в точном соответствии методологии IDEF1X получаемые схемы отношений удовлетворяют 4НФ; дополнительная нормализация отношений на этапе даталогического проектирования в примерах не рассматривается.

9. В примерах приводится описание внутренней схемы БД средствами языка описания данных, в качестве которого в реляционных СУБД используется подмножество языка SQL. Подробное описание языка можно найти в документации используемых на практике СУБД, а также в [1, 16]. В примерах приводятся фрагменты определения БД: предложения CREATE TABLE (создать таблицу) и ALTER TABLE (изменить таблицу).

10. В примерах приводятся предложения SQL, соответствующие стандарту SQL/92. Особенности языка, специфические для каждой конкретной СУБД (например, задание альтернативных ключей, построение уникальных индексов), в примерах не рассматриваются.

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

4.2. Проектирование базы данных "Школа"