alan_beaulieu-learning_sql-ru (Учебник по SQL), страница 3

Изза громоздкости бумажных баз данных одними из первыхкомпьютерных приложений были разработаны системы баз данных(database systems) – средства компьютеризированного хранения и извлечения данных. Поскольку система БД хранит информацию в элек14Глава 1. Немного историитронном виде, а не на бумаге, она может быстрее извлекать данные,индексировать их разными способами и поставлять своим пользователям самую свежую информацию.В первых системах БД информация хранилась на магнитных лентах.Количество лент во много раз превышало количество устройств считывания, поэтому техническим специалистам приходилось постоянноменять ленты, чтобы предоставить ту или иную запрашиваемую информацию.

Поскольку объем памяти у компьютеров той эпохи был невелик, при многократных запросах одних и тех же данных обычнотребовалось многократное считывание этих данных с магнитной ленты. Хотя эти системы БД и были существенным усовершенствованиемпо сравнению с бумажными БД, им было еще далеко до возможностейсовременных технологий.

(Современные системы БД могут работатьс терабайтами данных, распределенными по многим дискам с быстрым доступом, и держать в быстродействующей памяти десятки гигабайт этих данных; впрочем, я немного забегаю вперед.)Нереляционные системы баз данныхПервые несколько десятилетий данные в компьютеризированных системах БД хранились и представлялись поразному. Например, в иерархической системе баз данных (hierarchical database system) данныебыли представлены в виде одной или нескольких древовидных структур.

На рис. 1.1 показано, как с помощью древовидных структур можно организовать данные банковских счетов Джорджа Блейка (GeorgeBlake) и Сью Смит (Sue Smith).Джордж БлейкСью СмитКлиентыТекущие расходыСбереженияТекущие расходыДенежный рынокКредитный лимитСчетаДебит $100.00на 20040122Дебит $250.00на 20040309Дебит $1000.00на 20040325Кредит $25.00на 20040205Дебит $500.00на 20040327Кредит $138.50на 20040402Кредит $77.86на 20040404ТранзакцииРис. 1.1. Иерархическое представление информации по счетам15Введение в базы данныхИ у Джорджа, и у Сью есть собственное дерево, включающее их счетаи транзакции, производимые по этим счетам.

Иерархическая системабазы данных предоставляет средства для нахождения дерева конкретного клиента и последующего обхода этого дерева в поисках нужныхсчетов и/или транзакций. У каждого узла дерева может быть ни одного или один родитель и ни одного, один или много дочерних узлов. Такую конфигурацию называют иерархией с одним родителем (singleparent hierarchy).Другой распространенный подход, называемый сетевой базой данных(network database system), представляет собой наборы записей и наборы связей (links), определяющих отношения (relationships) между разными записями. На рис.

1.2 показано, как выглядели бы те же счетаДжорджа и Сью в такой системе.Чтобы найти транзакции, производимые по депозитному счету денежного рынка Сью, понадобилось бы сделать следующее:1. Найти клиентскую запись Сью Смит.2. Перейти по связи от клиентской записи Сью Смит к списку ее счетов.3. Просматривать цепочку счетов до тех пор, пока не будет найденсчет денежного рынка.КлиентыСчетаТранзакцииТекущие расходыДебит $100.00на 20040122Типы счетовТекущие расходыДжордж БлейкКредит $25.00на 20040205СбереженияДебит $250.00на 20040309СбереженияДебит $1000.00на 20040325Текущие расходыСью СмитДенежный рынокКредит $138.50на 20040402Денежный рынокКредитный лимитКредит $77.86на 20040404Кредитный лимитДебит $500.00на 20040327Рис.

1.2. Сетевое представление информации по счетам16Глава 1. Немного истории4. Перейти по связи от записи денежного рынка к списку его транзакций.Одну интересную особенность сетевых баз данных демонстрирует набор записей product (тип счета), на рис. 1.2 крайний справа. Обратитевнимание, что каждая запись product (Checking (текущие расходы), Savings (сбережения) и т.

д.) указывает на список записей account (счет),соответствующих этому типу счета. Поэтому доступ к записям accountможет быть осуществлен из нескольких мест (и через записи customer,и через записи product), что делает сетевую базу данных иерархией с несколькими родителями (multiparent hierarchy).И иерархические, и сетевые системы баз данных ныне живы и здоровы, хотя преимущественно в мире мэйнфреймов. Кроме того, иерархические системы БД возродились в службах каталогов, таких как ActiveDirectory компании Microsoft и Directory Server компании Netscape,а также с появлением XML (Extensible Markup Language, расширяемый язык разметки).

Однако начиная с 1970х годов все большую популярность приобретает новый способ представления данных, болеестрогий, но при этом более понятный и удобный.Реляционная модельВ 1970 году сотрудник исследовательской лаборатории IBM докторЕ. Ф. Кодд (E. F. Codd) опубликовал статью под названием «A Relational Model of Data for Large Shared Data Banks» (Реляционная модель данных для больших банков данных коллективного пользования), в которой предложил представлять данные как наборы таблиц. Вместо указателей для навигации по взаимосвязанным сущностям используютсяизбыточные данные, связывающие записи разных таблиц. На рис.

1.3представлена информация счетов Джорджа и Сью в таком контексте.На рис. 1.3 есть четыре таблицы, представляющие четыре обсуждаемые сущности: customer, product, account и transaction (транзакция). Посмотрев на таблицу customer, можно увидеть три столбца: cust_id(идентификационный номер клиента), fname (имя клиента) и lname (фамилия клиента). Ниже в таблице customer видим две строки: первая содержит данные Джорджа Блейка, вторая – данные Сью Смит. Максимально возможное количество столбцов в таблице отличается для разных серверов, но обычно это достаточно большое число, и с ним нетпроблем (Microsoft SQL Server, например, допускает до 1024 столбцовв таблице).

Число строк в таблице – это больше вопрос физическихвозможностей (т. е. определяется доступным дисковым пространством), чем ограничений серверов БД.Каждая таблица реляционной базы данных включает информацию,уникально идентифицирующую строку этой таблицы (первичный ключ(primary key)), а также дополнительные данные, необходимые для полного описания сущности. Возвращаясь к таблице customer: в столбцеcust_id каждому клиенту соответствует определенный номер. Напри17Введение в базы данныхКлиентcust_idСчетaccount_id product_cd cust_id balancefnamelname1ДжорджБлейк103CHK1$75.002СьюСмит104SA V1$250.00105CHK2$783.64106MM2$500.00107LO C20Тип счетаproduct_cdnameТранзакцияtxn_id txn_type_cd account_id amountdateCHKТекущие расходы978DBT103$100.00 20040122SAVСбережения979CDT103$25.00 20040205MMДенежный рынок980DBT104$250.00 20040309LOCКредитный лимит981DBT105$1000.00 20040325982CDT105$138.50 20040402983CDT105$77.86 20040404984DBT106$500.00 20040327Рис.

1.3. Реляционное представление информации по счетаммер, Джорджа Блейка можно уникально идентифицировать с помощью клиентского идентификатора (ID №). Никогда никакому другомуклиенту не будет присвоен такой же идентификатор, и этой информации достаточно, чтобы обнаружить данные Джорджа Блейка в таблицеcustomer.

Хотя в качестве первичного ключа можно было бы выбрать сочетание столбцов fname и lname (первичный ключ, состоящий из двухи более столбцов, называют составным ключом (compound key)), у двухи более человек, имеющих счета в банке, могут быть одинаковые именаи фамилии. Поэтому специально для первичных ключей в таблицу customer был включен столбец cust_id.Некоторые из таблиц также содержат информацию, используемую длянавигации к другой таблице.

Например, в таблице account есть столбецcust_id, содержащий уникальный идентификатор клиента, открывшего счет, и столбец product_cd, содержащий уникальный идентификатортипа счета, которому будет соответствовать счет. Эти столбцы называютвнешними ключами (foreign keys). Они служат той же цели, что и линии, соединяющие сущности в иерархической и сетевой версиях пред18Глава 1.

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

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

Правильное решение – хранить эту информацию в таблице customer. В другие таблицы следует включитьтолько cust_id. Также неправильно располагать в одном столбце несколько элементов данных, например в столбец name помещать имяи фамилию человека или в столбце address указывать улицу, город,страну и почтовый индекс. Процесс улучшения структуры базы данных с целью обеспечения хранения всех независимых элементов данных только в одном месте (за исключением внешних ключей) называют нормализацией (normalization).Вернемся к четырем таблицам на рис. 1.3; на первый взгляд можетбыть непонятно, как использовать их для поиска транзакций ДжорджаБлейка по его текущему счету. Вопервых, находим уникальный идентификатор Джорджа Блейка в таблице customer.

Затем строку в таблицеaccount, столбец cust_id которой содержит уникальный идентификаторДжорджа, а столбец product_cd соответствует строке таблицы product,столбец name которой содержит значение "Checking". Наконец, в таблицеtransaction находим строки, столбец account_id которых соответствуетуникальному идентификатору из таблицы account. Возможно, все этокажется сложным, но с помощью языка SQL может быть осуществленооднойединственной командой, как вы вскоре увидите.Немного терминологииВ предыдущих разделах были введены некоторые новые термины, поэтому приведем коекакие формальные определения. В табл. 1.1 приведены термины, используемые в данной книге, и их определения.Таблица 1.1. Термины и определенияТерминОпределениеСущность (entity)То, что представляет интерес для пользователей базы данных, например клиенты, запчасти, географическое положение и т.