Модель данных

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

Невизуальные компоненты Delphi служат для соединения приложения с таблицами БД. Они расположены на странице компонентов Data Access палитры компонентов в интегрированной среде разработки Delphi. Невизуальный компонент "перетаскивается" из палитры компонентов в форму разрабатываемого приложения. После этого Delphi автоматически описывает в форме экземпляр компонента указанного класса. Далее разработчик определяет свойства компонента, кодирует обработчики событий, где в программном коде вызывает необходимые ему методы компонента.

• Data Module

Невизуальные компоненты типа TDataModule применяются для централизованного хранения наборов данных в приложении, работающем с БД. Одним из главных удобств является приписывание каждому набору данных правил по управлению данными. Такие правила называются бизнес-правилами. Они обычно определяют реакцию системы при добавлении, изменении, удалении данных, при вводе ошибочных значений и реализуют блокировку действий, которые могут разрушить ссылочную и смысловую целостность БД.

Такие бизнес-правила, хранящиеся централизованно на уровне приложения, при использовании одного и того же набора данных в разных формах приложения, позволяют унифицировать поведение НД на уровне всего приложения.

Модель данных

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

Хотя понятие модели данных было введено Коддом, наиболее распространенная трактовка модели данных, по-видимому, принадлежит Кристоферу Дейту, который воспроизводит ее (с различными уточнениями) применительно к реляционным БД практически во всех своих книгах (см., например, [1.3]). Согласно Дейту реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части.

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

Манипуляционная часть модели данных содержит спецификацию одного или нескольких языков, предназначенных для написания запросов к БД. Эти языки могут быть абстрактными, не обладающими точно проработанным синтаксисом (что свойственно языками реляционной алгебры и реляционного исчисления, используемым в реляционной модели данных), или законченными производственными языками (как в случае модели данных SQL). Основное назначение манипуляционной части модели данных – обеспечить эталонный «модельный» язык БД, уровень выразительности которого должен поддерживаться в реализациях СУБД, соответствующих данной модели.

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

Отношение один-к-одному означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице. Например, если рассматривать таблицы, одна из которых содержит данные о сотрудниках предприятия, а вторая - профессиональные сведения, то можно сказать, что между этими таблицами существует отношение один-к-одному, поскольку для одного человека, информация о котором содержится в первой таблице, может существовать только одна запись, содержащая профессиональные сведения, во второй таблице.

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

Отношение много-к-одному аналогично рассмотренному ранее типу один-ко-многим. Тип отношения между объектами зависит от вашей точки зрения. Например, если вы будете рассматривать отношение между сделанными заказами и клиентами, то получите отношение много-к-одному.

Отношение много-ко-многим возникает между двумя таблицами в тех случаях, когда: одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.

27. Фразы BETWEEN, IN, LIKE.

Дата добавления: 2015-05-10