Методические указания для студентов специальности 2205, 0755 «Проектирование и технология эвс», «Комплексная информационная безопасность автоматизированных систем» (стр. 8 из 21)
Объектно-ориентированный подход достаточно прост. Прежде всего вспомним, что в информатике необходимо обеспечивать тесные связи между информационными системами и системами из реального мира которые они представляют. Во многих моделях свойственна потеря семантики, поэтому всегда существует риск, что разработанная система «неправильно построена». Она либо встречает сопротивление пользователей, либо не может решить поставленную задачу. Обычно объекты реального мира обладает некоторыми свойствами и применимыми к ним функциями, которые обеспечивают их определение и классификацию. Объекты связываются друг с другом либо на межобъектной основе в соответствии с бизнес правилами, либо с помощью некоторого вида наследования свойств. Далее, к объектам реального мира применяются некоторые операции и функции. Когда эти объекты моделируются и транслируются в структуры данных, например, в реляционную, имеет место потеря семантики. Даже при реализации моделей способных «удерживать» семантику, например, «сущность-связь» - результаты не обнадеживающие. Дело в том, что сами системы БД не поддерживают семантику внутренними средствами.
При разработке ООБД необходимо было создание структур, которые могли учитывать специфику приложений и удерживать семантику. Концепции ООБД:
Индивидуальность объектов. Каждый объект в объектно-ориентированной (ОО) системе имеет индивидуальный идентификатор, обычно называемый ID объекта или IDentificator. Использование ID позволяет изменять значение любого атрибута объекта, в том числе и атрибутов, образующих первичный ключ, не нарушая при этом ссылок на данный объект. Концепция ID берет начало от реляционных БД.
Атрибуты. Данный объект всегда имеет два аспекта: состояние и поведение. Состояние определяется множеством значений его атрибутов (или свойств, или экземплярных переменных, или полей). В ОО средах значение любого заданного атрибута должно подчиняться некоторым правилам, связанным с типом данных, с диапазоном или списком значений, а также с характеристикой, указывающей, единственное или множественное значение может быть задано и т.д.
Методы. Методы описывают поведение объекта. Благодаря передачи явных сообщений между объектами системы, вызов инкапсулированных методов и доступ к атрибутам заданного объекта осуществляется в соответствии с правилами данной ООСУБД.
Классы. Классы, называемые также типами, являются инструкциями, которые представляют собой группы объектов обладающих одним и тем же множеством атрибутов и методов. Классы могут быть примитивными, в этом случае не иметь атрибутов. Они могут иметь атрибуты и методы и в этом случае все объекты, относящиеся к данному классу имеют одни и те же множества атрибутов и объектов.
Иерархии классов и наследование. Подклассы наследуют атрибуты суперкласса и имеют некоторые новые атрибуты, специфические для принадлежащих им объектов.
Долговременное хранение. Корни ОО БД лежат в языках программирования. Создание нового долговременно хранимого объекта в языке программирования, порождает объект БД, который может использоваться непосредственно в программе без необходимости отображать его в структуры памяти языка программирования.
4. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
Существуют два основных подхода к моделированию предметной области при проектировании БД.
Первый подход, называемый функциональным, требует учитывать все особенности приложения, предназначенного для работы с проектируемой базой данных. Сначала составляется подробный список всех основных операций приложения. На основе списка задач определяются необходимые таблицы и их структуры. Использование Функционального подхода позволяет максимально оптимизировать структуру БД для выполнения указанного перечня задач. Такая структура в дальнейшем менее пригодна для изменения.
Второй подход объектный предлагает рассматривать предметную область без непосредственного учета требований приложений, которые будут работать с БД. При разработке структуры необходимо выделить в предметной области наиболее важные объекты. Сопоставить им отдельную таблицу. Использование второго подхода обеспечивает минимальное количество ошибок проектирования и зафиксировать реальные связи между объектами предметной области. Оба подхода используются при проектировании БД.
Рассмотрим шаги проектирования. Взглянем на фрагмент таблицы Customers (клиенты) из базы данных NorthWind. Она выглядит следующим образом:
| CustomerID | CompanyName | City | Country |
| ALFKI | Alfreds Futterkiste | Berlin | Germany |
| ANATR | Ana Trujillo Emparedados y helados | Mexico D.F. | Mexico |
| ANTION | Antonio Moreno Taqueria | Mexico D.F. | Mexico |
| AROUT | Around the Horn | London | UK |
Поскольку строки в таблице не упорядочены, нам нужна колонка (или набор из нескольких колонок) для уникальной идентификации каждой строки. Такая колонка (или набор колонок) называется первичным ключом (рrimary key). Первичный ключ любой таблицы обязан содержать уникальные непустые значения для каждой строки.
Выбор первичного ключа задача очень важная. Часто в проектируемых БД содержащих сведения о клиентах, в качестве первичного ключа выбирают фамилию имя отчество, что является неверным, поскольку эти три поля достаточно часто совпадают и при вводе фамилий чаще всего возникают ошибки ввода. Если в качестве идентификатора использовать наименование компании, то это тоже чревато неприятностями поскольку, например, наименование компании АТ & Т, А.Т. and T, Ma Bell с точки зрения человека это одна компания, а с точки зрения компьютера разные. Чаще всего используют специальный дополнительный столбец, который и будет использоваться в качестве первичного ключа.
Если первичный ключ состоит из более чем одной колонки, он называется составным первичным ключом (composite primary key). Типичная база данных обычно состоит из нескольких связанных таблиц. Ниже показан фрагмент таблицы Orders (заказы):
| OrderID | CustomerID | OrderDate | Freight | ShipAddress |
| 10254 | CHOPS | 11.07.96 | 22.98 | Hauptstr.31 |
| 10259 | CENTC | 18.07.96 | 3.25 | Sierras de Granada 9993 |
| 10265 | BLONP | 25.07.96 | 55.28 | 24,place Kleber |
| 10278 | BERGS | 12.08.96 | 92.69 | Berguvsvagen 8 |
| 10280 | BERGS | 14.08.96 | 8.98 | Berguvsvagen 8 |
| ... | ... | ... | ... | ... |
Поле CustomerID этой таблицы содержит идентификатор клиента,
разместившего данный заказ. Если нам нужно узнать, как называется компания, разместившая заказ, мы должны поискать это же значение идентификатора клиента в поле CustomerID таблицы Customers и в найденной строке прочесть значение поля CompanyName. Иными словами, нам нужно связать две таблицы, Customers и Orders, по полю CustomerID. Колонка, указывающая на запись в другой таблице, связанную с данной записью, называется внешним ключом (foreign key). Как видим, в случае таблицы Orders внешним ключом является колонка CustomerlD (рис. 16).
Иначе говоря, внешний ключ - это колонка или набор колонок, чьи значения совпадают с имеющимися значениями первичного ключа другой таблицы.
Подобное взаимоотношение между таблицами называется связью (relationship). Связь между двумя таблицами устанавливается путем присвоения значений внешнего ключа одной таблицы значениям первичного ключа другой.
Customers Orders
| OrderID (PK) |
 CostomerID (FK) |
| OrderDate |
| Freight |
| ShipAddress |
 CostomerID (PK) |
| CompanyName |
| City |
| Country |
Рисунок 16 Первичные и внешние ключи в таблицах Customers и Orders
Если каждый клиент в таблице Customers может разместить только один заказ, говорят, что эти две таблицы связаны соотношением один-к-одному (one-to-one relationship). Если же каждый клиент в таблице Customers может разместить ноль, один или много заказов, говорят, что эти две таблицы связаны соотношением один-ко-многим (one-to-many relationship) или соотношением master-detail. Подобные соотношения между таблицами используются наиболее часто. В этом случае таблица, содержащая внешний ключ, называется detail-таблицей, а таблица, содержащая первичный ключ, определяющий возможные значения внешнего ключа, называется master-таблицей. В нашем примере таблица Orders содержит внешний ключ CostomerID, который является внешним ключом. Таблица Customers является master-таблицей, а таблица Orders - detail-таблицей.
Группа связанных таблиц называется схемой базы данных (database schema). Информация о таблицах, их колонках (имена, тип данных, длина поля), первичных и внешних ключах, а также иных объектах базы данных называется метаданными (metadata).
Любые манипуляции с данными в базах данных, такие как выбор, вставка, удаление, обновление данных, изменение или выбор метаданных, называются запросом к базе данных (query). Обычно запросы формулируются на каком-либо языке, который может быть как стандартным для разных СУБД, так и зависящим от конкретной СУБД.