Даталогическое проектирование.
Цель даталогического проектирования – разработка логической структуры базы данных. Причем логическая структура базы данных, а также сама заполняемая данными база данных являются отображением реальной предметной области. Спроектировать логическую структуру базы данных означает определить все информационные единицы базы данных и связи между ними, задать их имена, типы и другие требуемые характеристики. Так как каждая система управления базами данных имеет собственные требования к назначению информационным единицам соответствующих характеристик, то даталогическое проектирование обязательно производится в среде конкретной СУБД.
Таким образом, исходными данными для разработки даталогической модели являются:
· инфологическая модель, представляющая собой отображение предметной области;
· система управления базами данных, определяющая правила логической организации информации в проектируемой базе данных.
Даталогическая модель включает в себя следующие основные компоненты:
· набор базовых структурных элементов для представления данных и схем данных (атрибуты, домены, схемы отношений);
· правила порождения ограничений на допустимые состояния данных (ограничения целостности);
· описание правил манипулирования данными.
В данном пособии рассматриваются вопросы построения только первых двух компонентов. Для каждой конкретной СУБД эти компоненты могут иметь уникальные особенности, поэтому цель пособия заключается в описании основных из них, наиболее общих для всех систем управления базами данных.
|
|
|
Концептуальная и внутренняя схемы баз данных, получаемые на разных этапах проектирования, отображают один и тот же объект реального мира. В связи с этим преобразование концептуальной схемы во внутреннюю выполняется в соответствии с определенными правилами, регламентирующими, как из описания предметной области на уровне инфологической модели получить описание той же предметной области на даталогическом уровне.
В результате даталогического моделирования в соответствии с реляционной моделью данных создается внутренняя схема. Для описания внутренней схемы базы данных используются операторы языка описания данных соответствующей СУБД. В современных реляционных СУБД наиболее распространенным ЯОД являются подмножества языка SQL (StructuredQueryLanguage). Для описания ограничений целостности используются соответствующие средства ЯОД и языка разработки приложений (SAL – SQL ApplicationLanguage), поддерживаемые конкретной СУБД.
Этап создания внутренней схемы сводится к следующим преобразованиям:
· Получение спецификаций внутренней схемы: перевод структурных спецификаций схемы базы данных с полноатрибутного IDEF1X-представления в описание на языке конкретной СУБД.
|
|
|
· Получение спецификаций ограничений целостности: перевод спецификаций ограничений целостности данных с языков IDEF1X, предикатов и естественного в описание на языке описания данных и программы на языке разработки приложений.
ER-моделирование. Нотация IDEF1X.
Метод IDEF1X, входящий в семейство стандартов IDEF, использует разновидность модели «сущность-связь» и реализован в ряде распространенных CASE-средств (в частности, ERwin).
Сущность в методе IDEF1X является независимой от идентификаторов, или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов, или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности.
Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой «/» и помещаемые над блоком.
Связь может дополнительно определяться с помощью указания мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей:
|
|
|
· каждый экземпляр сущности-родителя может иметь нуль, один или более одного связанного с ним экземпляра сущности-потомка;
· каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;
· каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;
· каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае — неидентифицирующей.
Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка.
Мощность связи может принимать следующие значения: N — нуль, один или более, Z — нуль или один, Р — один или более. По умолчанию мощность связи принимается равной N.
Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).
|
|
|
Пунктирная линия изображает неидентифицирующую связь.
Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой.
Сущности могут иметь также внешние ключи (ForeignKey), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках.
Дата добавления: 2018-02-18; просмотров: 1267; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!