Условный выбор

Оператор WHERE используется для указания отображения только определен­ных строк таблицы исходя из описанных условий. Предположим, например, что требуется отобразить характеристики деталей из таблицы PART, цена которых меньше $25. Для этого используется следующий программный фрагмент:

SELECT Part_Number, Part_Description, Unit _Pnce;

FROM PART;

WHERE Unit_Price < 25.00.

Запрос выдаст результат, показанный на рис. 7.11.

Объединение двух таблиц

Предположим, что требуется получить информацию о названиях, идентифика­ционных номерах и адресах поставщиков каждой детали, размещенной в базе дан­ных. Это можно сделать, объединяя таблицы PART и SUPPLIER, а затем извле­кая требуемую информацию. Запрос должен выглядеть таким образом:

SELECT PART.Part_Number, SUPPLIER.Supplier_Number, SUPPLIER.Supplier_Name, SUPPLIER.Supplier_Address;

FROM PART, SUPPLIER;

WHERE PART.Supplier_Number = SUPPLIER.Supplier_Number.

Результат запроса будет выглядеть так, как показано на рис. 7.12. А если вы хо­тите увидеть названия, адреса и коды поставщиков только для деталей 137 и 152, запрос должен быть сформулирован следующим образом:

SELECT PART.Part_Number, SUPPLIER.Supplier_Number, SUPPLIER.Supplier Name,

SUPPLIER.Supplier_Address.

Пропущена стор 370!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Entity-relationship diagram (диаграмма «сущность—связь»)

Методология документирования базы данных иллюстрирует отношения меж­ду разными сущностями в базе данных.

Normalization (нормализация)

Процесс создания небольших стабильных структур данных из сложных групп данных при проектировании реляционной базы.

На рис. 7.13 представлен документ, разработанный проектировщиками дан­ных базы, отражающий концептуальную модель данных со всеми взаимосвязями ее объектов (диаграмма «сущность—связь»). Прямоугольники представляют объ­екты, ромбы — взаимоотношения. Символы I или М на обоих концах ромба пред­ставляют отношения между объектами «один к одному», «один ко многим» или «многие ко многим». Рисунок 7.13 показывает, что объект ORDER может иметь больше чем одну PART, a PART может иметь только одного SUPPLIER. Это зна­чит, что многие детали может доставлять один поставщик. Атрибуты для каждого объекта перечислены рядом с объектом, ключевое поле подчеркнуто.

Для эффективного использования реляционной базы данных комплекс сгруп­пированных данных должен быть рационализован с целью избежания избыточ­ности данных и исключения затруднительных отношений «многие ко многим». Процесс создания небольших стабильных структур данных из сложных групп данных называется нормализацией. Этот процесс показан на рис. 7.14 и 7.15. В биз­несе, моделируемом здесь, заказ может иметь более чем одну деталь, но каждая

деталь поставляется только одним поставщиком. Если вы построили отношение под названием ORDER со всеми включенными здесь полями, вам надо будет по­вторять имя, описание и цену каждой детали заказа, а также имена и адреса каж­дого поставщика деталей. Такое отношение содержит то, что называется повто­ряющимися группами, поскольку в каждом заказе может быть много деталей и поставщиков и он действительно описывает множество объектов: детали, по­ставщиков, а также заказы. Более эффективный путь организации данных — разби­ение ORDER на меньшие отношения, каждое из которых будет описывать отдель­ный объект. Если мы будем идти шаг за шагом, а затем нормализуем отношение ORDER, то получим отношения, изображенные на рис. 7.15.

Если база данных тщательно спроектирована с ясным пониманием информа­ции, нужной для ведения бизнеса и ее дальнейшего применения, модель базы дан­ных будет, скорее всего, в некотором нормализованном виде. Многие реально су­ществующие базы данных не полностью нормализованы, поскольку это может быть не наиболее целесообразный путь удовлетворения требований бизнеса в от­ношении информации. Заметим, что реляционная база данных, изображенная на рис. 7.6, не полностью нормализована, поскольку в каждом заказе имеется более чем одна деталь. Проектировщики решили не использовать четыре отношения, показанные на рис. 7.15, поскольку большинство заказов в этом конкретном биз­несе содержит только одну деталь. Проектировщики сочли, что для этого бизнеса будет неэффективно использовать четыре разные таблицы.

Дата добавления: 2015-04-29