может кто-нибудь объяснить мне Три-схему архитектуру

Question

я новичок в системах баз данных, может кто-нибудь объяснить мне

Answer 1

так, как я узнал три уровня отличался от того, что вы изложены. Это было в 1980-х годах, поэтому вполне возможно, что то, чему я научился, больше не преподается. Вот оно:

Концептуальный уровень

Это действительно анализ данных, а не проектирования баз данных. Цель состоит в том, чтобы придумать модель, которая суммирует требования к информации о предлагаемой базе данных. Каждое значение, которое нужно сохранить, является экземпляром ATTRIBUTE. Атрибут описывает некоторый аспект как ENTITY, так и RELATIONHIP. Отношения являются ассоциациями между субъектами. Объекты - это основные объекты, которые составляют предмет.

Вы также можете получить DOMAIN для каждого атрибута. Домен - это набор возможных значений, которые может принимать атрибут.

Сущности, отношения, атрибуты и домены открыты при изучении предмета. Концептуальная модель почти ничего не говорит о структуре предлагаемого решения. Это приводит к созданию концептуальной модели, как правило, модели Entity-Relationship.

Logical Design

Первый этап проектирования включает в себя выражения атрибутов, обнаруженные выше в качестве компонентов отношений. Отношение состоит из кортежей и атрибутов. Атрибутами являются те, которые были обнаружены на концептуальном уровне. Состав отношений руководствуется некоторым принципом, в основном нормализацией.

Также добавлены иностранные ключи. Ключи служат для идентификации кортежей в отношениях, а внешние ключи служат для связывания кортежа, на который ссылаются другой кортеж, который ссылается на него. Внешние ключи реализуют отношения, обнаруженные выше на концептуальном уровне. Они играют ту же роль, что и указатели в базах данных графа.

Также добавлены ограничения. Это правила, которые ограничивают значения в атрибутах. Например, ограничение NOT NULL указывает, что данное значение не может быть опущено.

Результатом является логическая модель, как правило, реляционная модель.

Физического проектирование

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

Отношения выражаются в виде таблиц. Индексы добавляются для быстрого поиска. В качестве контейнеров для таблиц добавляются такие структуры, как табличные пространства. и т. Д.

Результатом является физическая модель, которая имеет все спецификации, необходимые для построения базы данных.

Следующим шагом будет преобразование физической модели в сценарий создания базы данных.

Внимание: если вы не создаете реляционную базу данных, создание реляционной модели на втором этапе может не иметь никакого смысла. Если вы не используете базу данных SQL, описание физической модели почти полностью неверно.Я включил их в список наиболее распространенных случаев.

Существует некоторое перекрытие между всем этим и вашей диаграммой, но есть и много расхождений.