alan_beaulieu-learning_sql-ru (865932), страница 3
Текст из файла (страница 3)
Из за громоздкости бумажных баз данных одними из первыхкомпьютерных приложений были разработаны системы баз данных(database systems) – средства компьютеризированного хранения и из влечения данных. Поскольку система БД хранит информацию в элек 14Глава 1. Немного историитронном виде, а не на бумаге, она может быстрее извлекать данные,индексировать их разными способами и поставлять своим пользовате лям самую свежую информацию.В первых системах БД информация хранилась на магнитных лентах.Количество лент во много раз превышало количество устройств считы вания, поэтому техническим специалистам приходилось постоянноменять ленты, чтобы предоставить ту или иную запрашиваемую ин формацию.
Поскольку объем памяти у компьютеров той эпохи был не велик, при многократных запросах одних и тех же данных обычнотребовалось многократное считывание этих данных с магнитной лен ты. Хотя эти системы БД и были существенным усовершенствованиемпо сравнению с бумажными БД, им было еще далеко до возможностейсовременных технологий.
(Современные системы БД могут работатьс терабайтами данных, распределенными по многим дискам с быст рым доступом, и держать в быстродействующей памяти десятки гига байт этих данных; впрочем, я немного забегаю вперед.)Нереляционные системы баз данныхПервые несколько десятилетий данные в компьютеризированных сис темах БД хранились и представлялись по разному. Например, в иерархической системе баз данных (hierarchical database system) данныебыли представлены в виде одной или нескольких древовидных струк тур.
На рис. 1.1 показано, как с помощью древовидных структур мож но организовать данные банковских счетов Джорджа Блейка (GeorgeBlake) и Сью Смит (Sue Smith).Джордж БлейкСью СмитКлиентыТекущие расходыСбереженияТекущие расходыДенежный рынокКредитный лимитСчетаДебит $100.00на 2004 01 22Дебит $250.00на 2004 03 09Дебит $1000.00на 2004 03 25Кредит $25.00на 2004 02 05Дебит $500.00на 2004 03 27Кредит $138.50на 2004 04 02Кредит $77.86на 2004 04 04ТранзакцииРис. 1.1. Иерархическое представление информации по счетам15Введение в базы данныхИ у Джорджа, и у Сью есть собственное дерево, включающее их счетаи транзакции, производимые по этим счетам.
Иерархическая системабазы данных предоставляет средства для нахождения дерева конкрет ного клиента и последующего обхода этого дерева в поисках нужныхсчетов и/или транзакций. У каждого узла дерева может быть ни одно го или один родитель и ни одного, один или много дочерних узлов. Та кую конфигурацию называют иерархией с одним родителем (singleparent hierarchy).Другой распространенный подход, называемый сетевой базой данных(network database system), представляет собой наборы записей и набо ры связей (links), определяющих отношения (relationships) между раз ными записями. На рис.
1.2 показано, как выглядели бы те же счетаДжорджа и Сью в такой системе.Чтобы найти транзакции, производимые по депозитному счету денеж ного рынка Сью, понадобилось бы сделать следующее:1. Найти клиентскую запись Сью Смит.2. Перейти по связи от клиентской записи Сью Смит к списку ее счетов.3. Просматривать цепочку счетов до тех пор, пока не будет найденсчет денежного рынка.КлиентыСчетаТранзакцииТекущие расходыДебит $100.00на 2004 01 22Типы счетовТекущие расходыДжордж БлейкКредит $25.00на 2004 02 05СбереженияДебит $250.00на 2004 03 09СбереженияДебит $1000.00на 2004 03 25Текущие расходыСью СмитДенежный рынокКредит $138.50на 2004 04 02Денежный рынокКредитный лимитКредит $77.86на 2004 04 04Кредитный лимитДебит $500.00на 2004 03 27Рис.
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 Relation al 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 2004 01 22SAVСбережения979CDT103$25.00 2004 02 05MMДенежный рынок980DBT104$250.00 2004 03 09LOCКредитный лимит981DBT105$1000.00 2004 03 25982CDT105$138.50 2004 04 02983CDT105$77.86 2004 04 04984DBT106$500.00 2004 03 27Рис.
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)То, что представляет интерес для пользователей ба зы данных, например клиенты, запчасти, географи ческое положение и т.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
