Базы данных |
Конспект лекций |
Раздел 1. Системы файлов и базы данных В этом разделе обсуждаются следующие темы: ·что такое база данных, для чего она нужна, и почему так важно проектирование базы данных; · происхождение современных баз данных от файлов и файловых структур · недостатки управления данными в файловых структурах · что такое система управления базой данных(СУБД) и как она взаимодействует с базой данных; · типы систем и модели баз данных.
Тема 1.1. Введение в базы данных Структурированные данные Хорошие решения требуют достоверной информации, которую приходится извлекать из неупорядоченных данных. Данными можно более эффективно управлять, если их разместить в базе данных (БД). Чтобы понять движущую идею проектирования баз данных, необходимо уяснить различие между неупорядоченными данными и упорядоченными, структурированными данными. Неупорядоченные данные это "сырье", необработанные сведения. Термин "сырье" здесь использован, чтобы подчеркнуть, что этот материал не подвергался никакой обработке с целью его структуризации. Предположим, что компания Восход контролирует все сделки по счетам-фактурам в своих двух подразделениях. Каждый из этих счетов содержит сведения примерно такого вида: · invoice number (номер счета-фактуры) = 300124 · invoice date (дата выписки счета) = 12-JAN-2002 · sales amount (сумма платежа) = $125.98 Далее предположим, что эти два подразделения компании Восход в первый квартал 2004 года и первый квартал 2005 года выписали 1380456 и 1453907 счетов-фактур соответственно. Следовательно, множество неупорядоченных сведений компании Восход будут содержать 2 834 363 номеров счетов-фактур, 2 834 363 дат выписки этих счетов и 2 834 363 сумм платежей. Принимая во внимание столь обильный фактический материал, к которому необходимо присовокупить информацию о сотрудниках каждого из этих двух подразделений, работавших в каждом из этих кварталов, можно ли всерьез думать о том, что руководство компании сможет извлечь какую-то продуктивную информацию об эффективности сделок в расчете на одного сотрудника каждого из этих двух подразделений? Скорее всего, нет. Управленческий персонал просто не сможет обработать такое количество счетов. С другой стороны, если мы предварительно обработаем этот материал, рассчитав поквартальный объем продаж для каждого из двух подразделений, а затем, разделив квартальные суммы сделок на расчетное число сотрудников в данном квартале, то получим результаты. Эти результаты, например, наглядно демонстрируют, что эффективность сделок в расчете на одного сотрудника в Подразделении 1 выше, чем в Подразделении 2. Более того, очевидно, что имеющийся разрыв в эффективности продаж в двух подразделениях увеличивается. Короче говоря, у руководителей компании теперь есть структурированная (упорядоченная) информация, которая может служить основой для принятия решения. Говорят, что мы живем в "век информации". Это означает, что получение достоверной, существенной и своевременной информации — ключ к решению любой задачи. В свою очередь выработка верных решений — ключ к успешному ведению бизнеса на мировом рынке. Выделим из всего сказанного выше некоторые основные положения. · Неструктурированные, "сырые"сведения — это основной источник информации. · Информация структурируется путем обработки"сырых" сведений. · В структурированной информации выявляется ее предназначение. · Достоверная, существенная и своевременная информация – ключ к принятию верных решений. · Верные решения – ключ к успеху предприятия на мировом рынке. Для достоверной, своевременной и значимой информации необходимы точные данные. Такие данные должны создаваться и храниться должным образом, в формате, обеспечивающем простоту доступа и обработки. Поскольку данные представляют собой важнейший базовый ресурс, ими необходимо тщательнейшим образом управлять. Управление данными это дисциплина, которая изучает методы создания, надлежащего хранения и извлечения данных. Принимая во внимание столь важную роль, которую играет информация в нашей жизни, стоит ли удивляться, что управление данными является основой деятельности любых предприятий, правительственных органов, сферы услуг и благотворительных организаций. База данных. Как правило, эффективное управление данными предполагает использование компьютерных баз данных. База данных - это интегрированная компьютерная структура совместного доступа, в которой размещаются следующие сведения: · данные конечных пользователей, т. е. сведения, отражающие сферу интересов конечного пользователя; ·метаданные, или данные о данных, с помощью которых осуществляется интегрирование (объединение) данных. Метаданные описывают свойства данных и совокупность отношений, которыми связаны данные, хранящиеся в БД. В некотором смысле база данных представляет собой очень хорошо организованную электронную картотеку, в которой мощное программное обеспечение, называемое системой управления базой данных, помогает управлять содержимым этой картотеки. Система управления базой данных (СУБД) представляет собой совокупность программ, с помощью которых осуществляются управление структурой базы данных и контроль доступа к данным, хранящимся в ней. СУБД позволяет нескольким приложениям или пользователям осуществлять совместный доступ к данным. Поскольку данные несут в себе весьма важные сведения, на основе которых и происходит структурирование информации, имеется целый ряд веских причин, по которым СУБД считается важнейшей составляющей всего информационного сообщества. Вот наиболее значимые из них. Поскольку роль данных так важна, в нашем распоряжении должен иметься надежный способ управления ими. · В состав СУБД входит язык запросов, позволяющий оперативно реагировать на нерегламентированные запросы (запрос это просто вопрос к БД, а нерегламентированный запрос это запрос к БД, возникающий в определенной ситуации и требующий немедленного выполнения). Например, если конечный пользователь имеет дело с большим количеством данных о продажах, то ему могут потребоваться оперативные ответы, допустим, на такие вопросы: · Каков объем продаж (в долларах) продукции за последние шесть месяцев? · Каков размер вознаграждения для каждого коммивояжера за последние три месяца? · Сколько клиентов имеют долг по кредиту в размере $3000 и более? · СУБД помогает создать рабочую среду, в которой конечным пользователям обеспечивается более удобный и хорошо управляемый доступ к данным, нежели имевшийся у них перед тем, как СУБД стала стандартным средством управления данными. Такой доступ позволяет конечным пользователям быстро реагировать на изменения в рабочей среде. Доступность данных в сочетании с инструментальными средствами, преобразующими данные в удобную форму представления, дает возможность конечным пользователям получать быстрые и информационно емкие решения, что и определяет успех или неудачу предприятий в сфере мировой экономики. · Широкий доступ к хорошо управляемым данным создает обобщенное представление обо всех операциях предприятия. Так, можно легко проследить, каким образом действия в одном сегменте предприятия оказывают влияние на другие сегменты. Одним словом, СУБД позволяет получить верное представление о картине деятельности предприятия в целом. · Вероятность противоречивости данных значительно уменьшается в тех БД, которые спроектированы должным образом и управляются с помощью СУБД. Более достоверные данные позволяют структурировать информацию наилучшим образом, что является основой наилучших решений. Рис. 1.1 иллюстрирует роль СУБД при взаимодействии между пользователем и базой данных. В сущности СУБД играет роль посредника между пользователем и БД, транслируя запросы пользователя в сложный код, необходимый для выполнения таких запросов. СУБД скрывает от прикладных программ, использующих БД, ее сложную внутреннюю структуру. Прикладные программы могут быть написаны программистом на каком-либо языке программирования (например, на ,или созданы с помощью сервисных программ СУБД. ![]() Рис. 1.1. СУБД управляет взаимодействием между конечным пользователем и базой данных Нужно всегда помнить, что СУБД представляет собой приобретенный вами коммерческий программный продукт, и у вас нет возможности вносить в него какие-либо изменения. Поэтому когда мы говорим о проектировании базы данных, то имеем в виду проектирование структуры БД, которая будет использована для хранения и управления данными, а не разработку программного обеспечения СУБД. После завершения проектирования базы данных СУБД берет на себя управление всеми сложными процедурами, необходимыми для перевода представления структуры данных проектанта в форму, удобную для компьютера. Почему так важно проектирование базы данных.Хорошая база данных не получается случайно, структура ее содержимого должка тщательно прорабатываться. Даже хорошая СУБД будет плохо работать с неудачно спроектированной базой данных. Правильно спроектированная БД облегчает управление данными и становится ценным поставщиком информации. Плохо спроектированная БД вероятнее всего станет накопителем избыточной информации, т. е. неоправданного дублирования данных. Избыточность, как правило, затрудняет выявление ошибок в данных. База данных содержит избыточные данные, если одна и та же информация об одном и том же логическом объекте хранится в разных местах (логическим объектом, сущностью — entity — считается персона, местоположение или предмет, сведения о которых подлежат сбору и хранению). Например, избыточность данных имеет место, если номер телефона клиента хранится и в файле клиентов, и в файле коммивояжеров, и в файле счетов-фактур. Избыточность данных может стать источником несовместимости данных, когда трудно определить, какая информация является правильной, а какая нет (например, если телефон клиента был заменен новым только в файле счетов-фактур, а в других остался прежним). В отчетах, выполненных на основе такой информации, могут содержаться противоречивые сведения в зависимости от того, какая из версий данных была использована. Короче говоря, неконтролируемая избыточность данных — типичный признак плохо спроектированной БД. Неудачно спроектированная база данных может служить источником ошибок, приводящим к неудачным решениям. Скверный проект базы данных, в конечном счете, может сам себя "исправить": организации, в которых используются плохо спроектированные БД, как правило, становятся банкротами (поскольку их менеджерам недоступна своевременная или, по крайней мере, достоверная информация), тем самым аннулируя и себя, и весь неудачный проект БД. Поскольку база данных является источником информации, ее проектирование становится предметом детального изучения в современных информационных средах. Проектирование базы данных — слишком важное дело, чтобы в данном случае полагаться "на авось". Вот почему в колледжах студенты изучают проектирование баз данных, вот почему малые и большие предприятия любых форм собственности посылают своих представителей на семинары, посвященные проектированию БД, и, наконец, именно поэтому специалисты по проектированию БД зачастую имеют столь солидный доход.
Тема 1.2. Предыстория баз данных: файлы и системы файлов Исторически сложилось так, что первые компьютерные приложения предназначались для решения организационных задач: обработка заказов и поставок, составление платежных ведомостей, разработка графиков выполнения работ и т. д. Такие приложения получали информацию из файлов, хранящихся на компьютере. Запросы следовали один за другим (сколько было продано, кем и кому?), а отчеты создавались с целью преобразования хранимых в компьютере данных к виду, удобному для руководства. В этой главе мы рассмотрим историю развития компьютерных файловых структур, создаваемых с целью получения более подробной и своевременной информации. Хотя файловые структуры в настоящее время постепенно уходят в прошлое, есть несколько веских причин для их детального изучения: · файловые структуры представляют собой интересную ретроспективу способов обработки данных; · философ Джордж Сантаяна однажды заметил, что "те, кто не помнит прошлое, обречены его повторить". Некоторые из дефектов, свойственных файловым структурам, могут вновь появиться в программном обеспечении БД, если его пользователям не будут известны ошибки управления данными; · осмысление основных свойств файловых структур упростит изучение более сложных методов проектирования БД; · если вам придется преобразовать устаревшую файловую структуру в базу данных, то в этом случае знание основных ограничений файловой структуры будет весьма полезным. Хранение в папках. В недавнем прошлом руководители практически любого малого предприятия обрабатывали (а некоторые обрабатывают и по сей день) важную информацию с помощью картотек. Такие картотеки традиционно представляли собой коллекцию папок с документами, каждая из которых помечалась и хранилась в картотечном ящике. Упорядочивание данных внутри папок с документами определялось предполагаемым использованием данных. В идеальном случае содержимое каждой папки было логически взаимосвязано. Например, папки в кабинете врача должны были содержат данные о пациентах — отдельная папка на каждого пациента. Все данные в такой папке описывали историю болезни отдельного пациента. Подобным образом служащий отдела кадров организовывал персональные данные по категориям служащих (клерки, технический персонал, коммерсанты, администрация и т. д.). При этом папка с пометкой "технический персонал" должна была содержать данные только сотрудниках, относящихся к техническому персоналу. До тех пор пока объем данных был относительно мал, и руководителю организации требовались всего лишь несколько отчетов, такие картотеки прекрасно исполняли роль хранилища данных. Однако по мере роста предприятия и повышения требований к отчетности обработка информации с помощью картотек становилась все более трудоемкой. Фактически поиск и использование данных среди возрастающего количества картотечных ящиков становились настолько долгими и обременительными, что возможность извлечения сколько-либо полезной информации постепенно сводилась к нулю. Вот лишь несколько вопросов, на которые владелец предприятия хотел бы получить ответ. ·Какой продукт продавался лучше всего на прошлой неделе? ·Каков объем сделок в долларах за текущий день, неделю, месяц, квартал, год? ·Каково положение дел с продажами в настоящий момент времени по сравнению с прошлой неделей, прошлым месяцем или прошлым годом? · Какие статьи расходов увеличились, уменьшились или остались на прежнем уровне в течение прошлой недели, месяца или года? · Не свидетельствует ли уровень продаж о необходимости пополнить складские запасы торговой точки? И этот список пополняется с каждым днем! Есть и более веские причины, побуждающие современного руководителя анализировать все больший объем информации. Деятельность некоторых предприятий — например чартерных авиационных компаний — строго регулируется правительством. Руководители таких компаний должны выпускать объемистые подробные квартальные отчеты, содержимое которых тщательно проверяется. Создание такой отчетности и ответы на различные вопросы во время периодических внеплановых проверок, выполняемых федеральными службами, требует весьма эффективного доступа к данным. К сожалению, получить такой отчет с помощью старинной картотеки практически невозможно. Ведь фактически руководителям потребуются недели интенсивной работы для создания отчетности, которую необходимо ежеквартально представлять в правительственные органы, даже при том условии, что картотека содержится в идеальном состоянии. В результате руководитель предприятия приходит к мысли о необходимости создания компьютерной системы обработки данных и создания требуемых отчетов. Хранение в файлах. Перевод картотеки в соответствующую файловую структуру компьютера был достаточно сложной технической задачей. По этой причине возникла потребность в профессионалах особого рода — специалистах по обработке данных (Data Processing specialist, DP), которых необходимо было нанять или "взрастить" из имеющихся сотрудников. DP-специалист умел строить необходимые структуры файлов, зачастую разрабатывая и программное обеспечение, помогающее управлять данными в таких структурах, а также писал прикладные программы, которые автоматически создавали необходимые отчеты на основе данных файла. В то время было порождено огромное число компьютеризованных систем файлов. Изначально компьютерные файлы в файловой структуре были очень похожи на документы картотеки. Простейший пример пользовательского файла данных для небольшой страховой компании, историю которой мы далее и рассмотрим, представлен на рис. 1.2.
![]()
C_NAME - Имя клиента Рис. 1.2 Структура пользовательского файла Customer
Краткий основной словарь, которым оперируют пользователи систем файлов, приведенный в табл. 1, поможет вам лучше понять дальнейшие рассуждения. Таблица 1.1. Основная терминология файловых систем ![]() Используя терминологию файловых систем, представленную в табл.1.l, мы можем идентифицировать компоненты файла, показанные на рис. 1.2. Обратите внимание что файл CUSTOMER (клиент), представленный на рис. 1.2, содержит 10 записей. Каждая запись состоит из девяти полей: C_NAME (имя), C_PHONE (телефон C_ADDRESS (адрес),C_ZIP(почтовый индекс),(имя),A_PHON (телефон), ТР (тип), АМТ и REN. Все 10 записей хранятся в именованном файле. Поскольку файл, представленный на рис. 1.2, содержит информацию о клиенте, файлу присвоено имя CUSTOMER. На основе содержимого файлов типа CUSTOMER DP-специалист писал программы, создававшие необходимые отчеты для коммерческого отдела: Со временем писались дополнительные программы, которые создавали новые отчеты. Хотя для определения содержимого отчета и написания программы требовалось какое-то время, руководитель коммерческого отдела не сожалел о старой доброй картотеке — компьютер экономил массу времени и сил. Отчеты производили должное впечатление, а возможность выполнять сложный поиск помогала извлекать информацию, необходимую для принятия верных решений. Затем в коммерческом отделе был создан файл с названием SALES (продажи), помогающий следить за ежедневными сделками. По мере необходимости получения новых отчетных форм были созданы дополнительные файлы. На самом деле успешная деятельность коммерческого отдела стала столь очевидной, что и руководитель отдела кадров попросил привлечь DP-специалиста для автоматизации обработки платежных ведомостей, а также других функций. В результате DP-специалиста попросили создать файл AGENT (агенты), представленный на рис. 1.3. Данные в файле AGENT использовались для выписки чеков, отслеживания уплаты налогов, итоговых результатов страхования и т. д. ![]()
A_NAME - Имя агента Рис. 1.3. Содержимое файла AGENT По мере роста числа файлов небольшая файловая структура, наподобие представленной на рис. 1.4, все разрасталась и разрасталась. Каждый файл в этой системе принадлежал сотруднику или отделу, по заказу которого он был создан. ![]() ![]() Рис. 1.4. Простейшая система файлов По мере роста системы файлов объем задач программирования рос еще быстрее, поэтому DP-специалисту разрешили принять на работу дополнительный штат программистов. Возросший размер системы файлов к тому же стал причиной приобретения нового компьютера с более мощными ресурсами. После приобретения компьютера и приема на работу программистов DP-специалист практически перестал заниматься программированием и стал уделять основное внимание управлению техническими ресурсами и кадрами. Поэтому DP-специалист получил должность руководителя отдела обработки данных — DP-менеджера. Несмотря на эти организационные изменения, все же основная деятельность нового DP-отдела сводилась к программированию, и неминуемо DP-менеджер большую часть своего рабочего времени исполнял роль старшего программиста-наблюдателя и занимался поиском ошибок в программах.
Тема 1.3. Оценка системы файлов Несмотря на то, что в этом разделе критикуется производительность файловых структур, необходимо помнить, что они служили верой и правдой в течение двух десятков лет, а это очень большой отрезок времени по меркам стремительной компьютерной эры. Приводимая здесь критика преследует две основные цели:
1.3.1. Управление системой файлов Алгоритмизация даже простейшей задачи поиска требует достаточно интенсивного использования языков программирования третьего поколения (third-generation language — 3GL). Эти языки программирования предполагают, что программист должен определить как то, что необходимо сделать, так и то, как это необходимо выполнить. К языкам 3GL относятся, например, COBOL (COmmon Business-Oriented Language), BASIC (Beginner's All-purpose Symbolic Instruction Code) и FORTRAN (FORmula TRANslation). Программирование на таких языках требует значительных затрат времени и высокого профессионализма. Поскольку простейший файл, представленный на рис. 1.4, достаточно сильно отличается от физического способа хранения представленной в нем информации на носителе, программист должен быть знаком с физической структурой дисковых файлов, т. е. знать, как и где файлы хранятся на носителях компьютера. Поэтому программист должен определить маршрут доступа к данным каждого файла, на который имеются ссылки в программе. Такой маршрут рассчитывается по сложному алгоритму и позволяет установить точное местоположение различных компонентов файла и системы, а также свойства связанных с ними данных. По мере того, как система файлов становится более сложной, маршруты доступа все труднее поддаются контролю, и это может стать причиной системных сбоев. Необходимость написания программ на языках 3GL для создания даже самых простых отчетов делает практически невозможной обработку нерегламентированных запросов. Принятых на работу DP-специалистов, работающих со сложившейся системой файлов, нередко просят создать новые отчеты. Чаще всего они вынуждены давать ответ вроде "зайдите на следующей неделе" или даже "через месяц". Однако если информация вам требуется немедленно, то вполне вероятно, что "на следующей неделе" или в "следующем месяце" она не будет иметь никакого смысла. По мере расширения системы файлов усложняется и системное администрирование. Каждый файл должен иметь собственную систему управления, состоящую из программ, дающих клиентам возможность выполнять следующие действия: · создание структуры файла · добавление данных в файл; · удаление данных из файла; · изменение данных в файле; · вывод содержимого файла. Даже простая система, состоящая из 20 файлов, потребует 5х20 = 100 управляющих программ. Если к каждому из этих файлов осуществляется доступ из 10 различных программ, генерирующих отчеты, то необходимо написать дополнительно 20х10=200 программ. Поскольку нерегламентированные (в данном случае незапрограммированные) запросы невозможны, число программ генерации отчетов быстро умножается. А если каждый отдел организации является единоличным хозяином своих данных и создает собственные файлы, то общее число таких файлов растет очень быстро. Тщательное планирование структур файлов является очень важной обязанностью DP-менеджеров, поскольку изменение существующей структуры файла — дело слишком трудоемкое. Например, чтобы изменить только одно поле в исходном файле CUSTOMER, потребуется написать программу, которая должна выполнять следующие действия.1. Поместить новую файловую структуру в специальный раздел памяти компьютера, называемый буфером. 2. Открыть исходный файл, используя другой буфер. 3. Считать запись из исходного файла. 4. Преобразовать исходные данные в форму новой структуры хранения. 5. Записать преобразованные данные в новую файловую структуру. Затем исходный файл удаляется. Наконец, все программы, использующие файл CUSTOMER, должны быть настроены для использования новой структуры файла. Фактически любые изменения в структуре файла потребуют, как минимум, изменить все программы, использующие информацию из этого файла. Любые изменения являются источником ошибок и требуют дополнительных временных затрат на отладку. Поговорка "семь раз отмерь, один раз отрежь" особенно справедлива при работе с системой файлов, поскольку даже при малейших изменениях в файловой структуре приходится менять все программы доступа к данным. В этой среде безопасность, например, защита данных надежным паролем, блокировка фрагментов файла или разделов самой системы и другие средства обеспечения защиты информации, трудно программируется и поэтому обычно не соблюдается. Если и предпринимаются попытки обеспечить безопасность данных и системы, то, как правило, в очень ограниченных пределах. Структура файлов и недостаточная безопасность создают определенные трудности при накоплении данных. Такая организация обработки данных способствует их монопольному использованию, побуждая таким образом хранить одну и ту же информацию в различных местах. Поскольку маловероятно, что данные, хранящиеся в разных местах, будут всегда согласованно обновляться, то файлы часто содержат различные версии одних и тех же данных. Результат использования системы файлов легко предсказать: хотя такой подход легко реализуется на начальных стадиях компьютерной обработки данных, по мере роста системы она, скорее всего, выйдет из-под контроля. Очевидно, что системы файлов не могут удовлетворять современным требованиям, предъявляемым к информационным системам.
1.3.2. Структурная зависимость и зависимость по данным В предыдущем разделе мы обсудили, как изменение в любой файловой структуре (например, добавление или удаление поля) влечет за собой переделку всех программ, использующих этот файл. Такая модификация необходима, потому что система файлов обладает структурной зависимостью (structural dependence), т. е. доступ к файлу зависит от его структуры. Даже изменение свойств данных файла, например, изменение типа поля с integer (целое) на decimal (десятичное) потребует изменений во всех программах, использующих этот файл. Поскольку необходимо поменять все программы доступа к данным при любых изменениях характеристик данных файла, говорят, что система файлов обладает зависимостью по данным (data dependence). Практический смысл
зависимости по данным состоит в разнице между логическим форматом данных (data
logical format — как видит данные человек) и физическим форматом данных (data physical
format — как "видит" данные компьютер). Поэтому всякая программа,
получающая доступ к файлу, должна сказать компьютеру не только, что надо
делать, но и как делать. Именно поэтому каждая программа должна содержать
строки кода, в которых задаются способ открытия файлов конкретного типа,
спецификация его записей и определения полей. Зависимость по данным, таким
образом, делает систему файлов чрезвычайно громоздкой и с точки зрения
программирования, и с точки зрения управления.
Если в файловой системе возникли трудности с обработкой данных, то весьма вероятно, что в различных местах хранятся одинаковые данные. Например, на рис.1. 2 и 1.3 имена агентов и номера телефонов встречаются как в файле CUSTOMER, так и в файле AGENT, хотя на самом деле достаточно иметь всего лишь один набор имен агентов и список их телефонных номеров. Если же они встречаются в нескольких местах, то имеет место избыточность данных. Неконтролируемая избыточность может стать причиной возникновения следующих проблем. Ошибки оператора наиболее вероятны при вводе сложных элементов (например, десятизначных телефонных номеров) в несколько разных файлов и/или при часто повторяющемся вводе в один или более файл. На самом деле, файл CUSTOMER содержит такую ошибку ввода: в третьей записи файла CUSTOMER переставлены цифры в номере телефона агента (615-882-2144 вместо 615-882-1244). В файл CUSTOMER легко могут быть внесены несуществующие имена агентов и номера телефонов, и клиентам вряд ли понравится, если страховое агентство предоставит в их распоряжение имя и номер телефона несуществующего агента. К тому же должен ли отдел кадров выплачивать премиальные и предоставлять льготы несуществующим агентам? Фактически любая ошибка ввода данных, например, связанная с неправильно введенным именем или некорректным номером телефона, является причиной нарушения целостности данных. · аномалии модификации. Если у агента Ивановой меняется номер телефона, то новый номер должен быть введен в каждую запись файла CUSTOMER, в которой упоминается номер телефона Ивановой. В нашем случае необходимо сделать только три исправления. В больших системах файлов такие исправления, возможно, придется делать в сотнях, а может, и тысячах записей. Очевидно, что при этом вероятность возникновения несовместимости в данных очень высока; · аномалии включения. Чтобы добавить нового клиента в файл CUSTOMER. также необходимо ввести данные по агенту. Если мы добавляем несколько сотен новых клиентов, то нам придется ввести и несколько сотен имен агентов и не меньшее количество телефонных номеров. Опять-таки в этом случае высока вероятность несовместимости данных; · аномалии удаления. Если агент Петров удаляется из списка AGENT, все его клиенты в файле CUSTOMER будут связаны с несуществующим агентом. Для разрешения этой проблемы мы должны изменить все записи, в которых встречаются имя Петрова и его телефон.
Использовать систему базы данных, конечно же, намного привлекательнее, чем работать с системами файлов, где имеется столько проблем. В отличие от систем файлов с большим количеством не связанных друг с другом файлов, база данных состоит из логически взаимосвязанных данных, размещенных в едином хранилище. Поэтому БД предоставляет конечным пользователям иной способ управления данными, доступа к ним и хранения. Система управления базой данных, представленная на рис. 1.5, обладает целым рядом преимуществ по сравнению с системой управления файлами, представленной на рис. 1.4, и обеспечивает решение проблемы несовместимости данных, аномалии данных, зависимости по данным и структурной зависимости. ![]() ![]() Рис. 1.5. Отличие базы данных от системы файлов Необходимо помнить, что СУБД это всего лишь один из множества важнейших компонентов системы базы данных. Может быть, СУБД и можно считать "сердцем" системы базы данных, однако для обеспечения жизнедеятельности такого сложного организма одного сердца недостаточно. Далее мы рассмотрим, что представляет собой система базы данных, из каких компонентов она состоит и каким образом СУБД встраивается в общую картину системы базы данных.
1.4.1. Среда системы базы данных Термин система базы данных относится к организации компонентов, определяющих и регулирующих сбор, хранение, управление и использование данных в среде базы данных. С точки зрения общего управления система базы данных состоит из пяти основных частей, представленных на рис. 1.6: аппаратные средства, программное обеспечение, люди, процедуры и данные. ![]() Рис.1.6. Среда системы базы данных · Системное программное обеспечение управляет всеми компонентами оборудования и обеспечивает доступ к нему всем другим приложениям, работающим на компьютере. Примеры системного программного обеспечения: DOS, операционные системы семейства Windows, устанавливаемые на персональных компьютерах, системы UNIX и VMS, используемые, как правило, на компьютерах средней мощности, и операционная система MVS, которая устанавливается на мэйнфреймах фирмы IBM. · Программное обеспечение СУБДуправляет базой данных. Примерами СУБД являются приложения Access и SQL Server корпорации Microsoft, Oracle корпорации Oracle и DB2 фирмы IBM. · Прикладные программы и утилиты предназначены для получения доступа к данным и манипулирования ими в среде СУБД, а также в вычислительных средах, где необходимо выполнять такие действия. Прикладные программы (приложения) в большинстве случаев используются для получения доступа к данным, хранящимся в БД, для составления отчетов и таблиц, помогающих в принятии решений. · Системные администраторы наблюдают за основными операциями системы. · Администраторы базы данных (DBA) управляют работой СУБД и обеспечивают функционирование базы данных. · Проектировщики базы данных проектируют структуру БД. Они, в сущности, являются архитекторами базы данных. Если БД спроектирована плохо, то даже лучшие прикладные программисты и самые просвещенные DBA не смогут обеспечить ее должное функционирование. Используя более древнюю аналогию, можно сказать, что даже лучшие каменщики и плотники не смогут построить хорошее здание по плохому проекту. Поскольку предприятия стремятся оптимизировать свои информационные ресурсы, должностные инструкции проектировщиков баз данных были (относительно недавно) в значительной степени переработаны с тем, чтобы расширить круг обязанностей проектировщиков и повысить их ответственность. · Системные аналитики и программисты color:black'> пишут и реализуют прикладные программы. Они проектируют и создают формы ввода данных, отчеты и процедуры, с помощью которых конечные пользователи получают доступ к данным и возможность манипулирования ими. · Конечные
пользователи это те,
кто использует прикладные программы для выполнения ежедневных операций
предприятия, например, продавцы, инспекторы, руководители и управляющие - все
они считаются конечными пользователями. Конечные пользователи высшего уровня
используют информацию, полученную из базы данных, для решения тактических и
стратегических задач предприятия.
Очевидно, что база данных добавляет некое новое измерение в структуру управления предприятия. В целом эта административная структура зависит от размера предприятия, его предназначения и культуры его производства. Поэтому системы баз данных могут создаваться и функционировать на самых разных уровнях сложности и с весьма широким диапазоном правил и стандартов. Сравните, например, небольшую систему учета проката видеокассет с системой государственного страхования. Системой проката видеокассет могут управлять два человека; в состав ее оборудования входит, скорее всего, один персональный компьютер; процедуры, по всей вероятности, самые простые, а объем информации не так уж и велик. В системе государственного страхования, скорее всего, имеются, как минимум, один системный администратор, несколько штатных администраторов базы данных и несколько проектировщиков и программистов; в состав оборудования, по всей вероятности, входит несколько мэйнфреймов, расположенных в разных точках страны; процедур достаточно много, они сложны и тщательно проработаны, а объем обрабатываемой информации очень велик. Кроме понимания
того, что уровень сложности разрабатываемой системы базы данных определяется
сферой деятельности предприятия и его масштабом, руководство предприятия должно
принимать во внимание еще и тот факт, что разработка базы данных должна быть
экономически выгодна и эффективна как с тактической, так и со стратегической
точки зрения. Разработка системы стоимостью миллион долларов для решения
копеечной проблемы едва ли может служить примером правильного выбора системы
базы данных или верного проектного решения. Очевидно, что существующие
технические решения на основе применения базы данных склоняют чашу весов в
сторону использования таких систем. Учитывая высокий уровень требований,
предъявляемых к базам данных и современным технологиям, нелишним будет обсудить
несколько различных типов систем управления базами данных.
1.4.2. Типы систем управления базами данных Системы управления базами данных (СУБД), составляющие основу систем баз данных, можно классифицировать по количеству пользователей, местоположению сайта БД, а также по ожидаемому способу и сфере использования. По количеству пользователей СУБД можно подразделить на однопользовательские (single-user) и многопользовательские (multiuser). Однопользовательская СУБД обслуживает в данный момент времени только одного клиента. Другими словами, если пользователь А использует базу данных, то пользователи В и С должны подождать, пока пользователь А не закончит работу с базой. Если однопользовательская БД развернута на персональном компьютере, то ее называют настольной базой данных (desktop database). В противоположность этому, многопользовательская СУБД может обслуживать несколько пользователей одновременно. Если многопользовательская база данных обслуживает относительно небольшое число пользователей (менее 50) или, скажем, отдел предприятия, то она называется базой данных рабочей группы (workgroup database). Если же база данных используется в рамках всего предприятия и обслуживает большое число (более 50, как правило, сотни) пользователей нескольких подразделений и отделов, то такая БД называется базой данных предприятия (enterprise database). Сайт, на котором размещена БД, тоже может служить признаком классификации СУБД. Например, СУБД, которая обслуживает базу данных, размещенную на одном сайте, называется централизованной СУБД (centralized DBMS). СУБД, обслуживающая базу данных, распределенную по нескольким различным сайтам, называется распределенной СУБД (distributed DBMS). Возможно, классификация СУБД по способу применения и сфере использования базы данных является самым распространенным и общепризнанным способом. Например, транзакции по продаже товаров или услуг, платежи и закупка товаров представляют собой важнейшие каждодневные операции. Время, которое отводится на выполнение таких транзакций, весьма ограничено, а результат их действий должен фиксироваться и вступать в силу немедленно. СУБД, которые управляют работой баз данных, спроектированных для транзакций "немедленного отклика", называются транзакционными СУБД (transactional DBMS) или рабочими СУБД (production DBMS)1. В отличие от них база данных поддержки решений (decision support database) предназначена в основном для получения необходимой информации при выработке стратегических или тактических решений на уровне среднего и высшего руководства предприятия. Поддержка решений, обеспечиваемая системой поддержки решений (decision support system, DSS), как правило, требует широкомасштабной обработки данных (манипулирования данными) для извлечения полезной информации из данных, полученных за некоторый длительный промежуток времени, с тем, чтобы принять верное решение по ценовой политике, спрогнозировать сбыт, состояние рынка и т. д. Поскольку основная часть информации DSS извлекается из накопленных за некоторое время сведений, фактор времени, затраченного на получение данных в такой системе, не имеет столь существенного значения, как в транзакционных базах данных. К тому же информация систем DSS, как правило, базируется на большом объеме данных, полученных из различных источников. Чтобы облегчить поиск в этом море информации, структура базы данных DSS несколько отличается от структуры транзакционных БД. На самом деле, для обозначения баз данных, предназначенных для систем DSS, используется термин хранилище данных, или банк данных (Data Warehouse, DW). Совершенно ясно — хороший проект базы данных предполагает, что проектировщик БД точно знает, для чего предназначается проектируемая база. При проектировании транзакционных БД основное внимание уделяется целостности и непротиворечивости данных, а также скорости выполнения операций. При проектировании базы данных поддержки решений акцент делается на методах обработки данных, накопленных за длительное время. Проектирование баз данных, предназначенных для централизованного однопользовательского применения, требует иного подхода, нежели проектирование распределенных многопользовательских БД.
СУБД выполняет несколько очень важных функций, обеспечивающих целостность и, непротиворечивость данных, хранящихся в БД. Большинство этих функций для конечного пользователя незаметны, и основную их часть выполняет СУБД. Сюда включаются управление словарем данных, управление хранением данных, преобразование данных и их представление, обеспечение безопасности, обслуживание многопользовательского доступа, резервное копирование и восстановление, целостность данных, языки доступа к данным и интерфейсы прикладного программирования, я также интерфейсы взаимодействия с базой данных. · конечный пользователь может получать ответ на запросы, заполняя экранные формы с помощью выбранного им браузера; · с помощью СУБД можно автоматизировать публикациюформ отчетов в Интернете с помощью Web-форматирования, что позволяет просматривать их с помощью любого браузера; · с помощью СУБД можно подключаться к независимым системам для распространения информации по электронной почте (e-mail) или с помощью другие эффективных приложений, например, Lotus Notes. Как видите, СУБД выполняет основную часть рутинных процедур по обработке информации, которую когда-то в среде системы файлов должны были выполнять DP-специалисты, причем делает это куда искуснее и изощреннее. Более того, СУБД выполняет эту работу без утомительного и долгого программирования, которое было уделом систем файлов. Вдобавок, СУБД предоставляет рабочую среду, где используются строго определенные процедуры и стандарты. Поэтому теперь основой деятельности DP-специалистов или DP-менеджеров становится не утилитарное программирование, а решение проблем управления ресурсами данных предприятия и администрирование сложного программного обеспечения БД. Поскольку бывшие DP-менеджеры систем файлов получили столь широкие функциональные обязанности в среде базы данных, их вполне можно выдвигать на роль системных администраторов. На первых порах, когда среда системы базы данных довольно проста, системные администраторы и выполняют задачи управления и получают практический опыт администрирования БД. По мере расширения базы данных системный администратор обычно назначает одного или двух администраторов базы данных, которые оценивают качество проекта БД, поддерживают программное обеспечение базы данных, присваивают полномочия отдельным пользователям на использование БД и координируют разработку приложений на основе имеющихся информационных ресурсов. |
назад | содержание | вперед